Researching for how to get my SpaceNavigator 3dmouse, which is a fully HID compliant 6 DOF device, I came across this thread

http://old.nabble.com/Adding-SpaceNavigator-support-td15100788.html

Dated Jan. 2008. links to a thread still sticky on the 3dconnexion forums

http://www.3dconnexion.com/forum/viewtopic.php?t=1917

the last contribution to which is noneless more than a year old. I successfully configured the Device to plug with X through evdev (maybe there is a better driver by now which I don't know of but evdev does quite well) and it is recognized as both, a regular xinput device and, if given the right props with udev, a readable raw input in /dev/input

However, nothing much too add to the threads mentioned as still I found no solution to what I'd call a major lack of operatability, that is the lack of configuration of the device on primarily GIMPs side.

In fact, nothing really works, so I can skip that part and make it short by saying what works, at least slighly. That is moving the cursor, if used as a InputDevice and, if read with Linux Input Controller directly from the rawhid (which I suppose is not the preferred way of using an input controller) zooming, scrolling and whatever else is mapped (I'll write another email concerning this in a second).

Conclusion: We utterly need consistent support for xinput devices (I don't consider "Linux Input Controllers" for reading out rawhid data a solution).

My suggested "solution" is the following:

For 2.8 or, if possible, as early as possible, branch efforts to a unified interface, enhancing the current "Extended Input Devices".

In detail:

The main issue is that one has to choose between reading rawhid data with "Linux Input" (which I think should only a back-up option since natively one doesn't have the necessary priviledges to access rawdata anyway) and employing a properly registered Xinput device through "Extended Input Devices". In the latter case you have absolutly no option to map anything and in former case you bypass X completely which makes little sense since X may have the necessary drivers.

After all X is the way to go but currently it's a mess of so many bugs that I would not know where to start filing them.

I got problems such as that if I got the Wacom stylus in the proximity zone I can't use the scroll-ring (wheel).

The Z-Axis of the 3dmouse (3) is mapped to pressure, yet that has no effect - it does not draw when the tablet is plugged in.

------------------------------------------ /!\ /!\
There is ABSOLUTLY NO way as far as I can see to use an xinput device and map its axes to do certain tasks such as scrolling or zooming - thats unbearable. I (would) have to employ it as "Linux Input" (which only works if its HID compliant, if im not mistaken) and then map actions to its discrete events which - as stated in the first thread - completely bypasses any sort of sensitivity.

That said, the "Linux Input Controller" is virtually useless for any device which has continous output because it takes not into account any sort of repeat rate or graduality. -----------------------------------------

I, as a user, would like to directly corelate the axis (x motion event!!!) to zoom, pan, color, etc! Therefore I say that this needs a coherent interface where such mappings can take place.

I think these major points which can bring a great advantage for any professional who uses the appropriate input devices.

Im curious what you have to say!

Read my next mail!

best regards, --MD

A small PS: Enabling "Screen" for the 3dmouse device in Extended Input Devices renders the mouse dead for drawing.

There is a sliding border between what is a canonical input device and what is absused, so to say, as an input device. Consider my tablet (Intuos). You say it has axis with fixed meaning? I beg to differ! The device provides a 6-dimensional motion event. Channel 0 to 4 being more or less what you said, fixed with something that would not make sense to change (I'll revise that in a second), then channel 5 corresponds to the wheel on the tablet. The driver also emits a button event when scrolling the wheel but at the same time it provides positional data in the motion vector.

GIMP/GTK accounts for the channel's existance, but GIMP does not know what to do with a "Wheel" channel, as what GTK identifies it, and can only handle the button events to be mapped to mouse-wheel events.

So much for the canonical input devices and their fixed meanings. I don't think anything is fixed and it just depends on the type of input device how likely one might want to change it. That's what I meant by a sliding line.

I also might want to map Tilt (which GIMP currently has no support for), which is channels 3 and 4 to something like color (or just brush size). As with the rather inconsistent way GIMP/GTK handles all this stuff right now, only one hardcoded channel, that is the channel identified as "Pressure" by GTK (usually 2) can have any effect. Every channel mapping is 100% hardcoded which is maybe not what you want with a canonical input device and is certainly not what you want if you use additional input devices.

And unfortunally, there is no way of fixing this somewhere else. GTK offers a way to swap channels and map buttons which is a complete redundancy to what a driver or xmodmap can do. But it offers no way to give the Axis actual meanings in the program, which is what only IT can and should do.

On 07/17/2010 09:54 PM, Alexia Death wrote:

Just so its said first, input stuff is business of GTK. Gimp conjumes what GTK provides.

On Saturday, July 17, 2010 22:45:07 Cedric Sodhi wrote:

I, as a user, would like to directly corelate the axis (x motion event!!!) to zoom, pan, color, etc! Therefore I say that this needs a coherent interface where such mappings can take place.

Any paint options are mapped via dynamics, try 2.7 from git and you'll see what I mean. Pan and Zoom are UI controlls and such part of a different concept. One that does not exist yet. This concept is where mapping axis of odd devices like navigator to UI and action control should be set.

I think these major points which can bring a great advantage for any professional who uses the appropriate input devices.

Tablets are paint and draw tools and their axis have fixed meanings. Chaninging that would be silly. Navigators and other such tools are separate business.

-- Alexia