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

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

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 

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 

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,

Gimp-developer mailing list

Reply via email to