Adding SpaceNavigator support
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
| Adding SpaceNavigator support | Ettore Pasquini | 26 Jan 02:56 |
| Adding SpaceNavigator support | Simon Budig | 26 Jan 03:22 |
| Adding SpaceNavigator support | Ettore Pasquini | 26 Jan 10:16 |
| Adding SpaceNavigator support | Sven Neumann | 27 Jan 10:51 |
| Adding SpaceNavigator support | Ettore Pasquini | 27 Feb 04:52 |
| Adding SpaceNavigator support | Ettore Pasquini | 28 Feb 04:16 |
| Adding SpaceNavigator support | Sven Neumann | 02 Mar 17:46 |
| Adding SpaceNavigator support | Ettore Pasquini | 03 Mar 21:46 |
| Adding SpaceNavigator support | Simon Budig | 04 Mar 10:40 |
| Adding SpaceNavigator support | Simon Budig | 04 Mar 10:27 |
| Adding SpaceNavigator support | Alexia Death | 04 Mar 16:05 |
| Adding SpaceNavigator support | Sven Neumann | 04 Mar 20:20 |
| Adding SpaceNavigator support | GSR - FR | 04 Mar 22:23 |
| Adding SpaceNavigator support | Sven Neumann | 05 Mar 08:49 |
| Adding SpaceNavigator support | GSR - FR | 05 Mar 19:47 |
| Adding SpaceNavigator support | Sven Neumann | 05 Mar 22:03 |
| Adding SpaceNavigator support | Sven Neumann | 04 Mar 21:30 |
Adding SpaceNavigator support
Hello everyone,
I work for 3Dconnexion (a Logitech company) and we make 3D input devices. We also care about popular 2D apps that could use the high sensitivity of our SpaceNavigator for panning and zooming. GIMP was under our radar and now we are considering to add support for our devices.
I am new to the GIMP code base so I wanted to ask some questions about the architecture first. What would be the best way (from a pure engineering standpoint) to integrate my code? Meaning, via a plugin or just into the main app? Are there modules for I/O events (to deal with tablets, controllers, etc) that I should start with and expand?
BTW let's not worry about licensing issues now. My code will obviously be shared and our devices are HID compliant, so no need to mess with proprietary drivers.
Thanks in advance,
Ettore
Adding SpaceNavigator support
Hi Ettore.
Ettore Pasquini (ettore_pasquini@3dconnexion.com) wrote:
I work for 3Dconnexion (a Logitech company) and we make 3D input devices. We also care about popular 2D apps that could use the high sensitivity of our SpaceNavigator for panning and zooming. GIMP was under our radar and now we are considering to add support for our devices.
I am new to the GIMP code base so I wanted to ask some questions about the architecture first. What would be the best way (from a pure engineering standpoint) to integrate my code? Meaning, via a plugin or just into the main app? Are there modules for I/O events (to deal with tablets, controllers, etc) that I should start with and expand?
BTW let's not worry about licensing issues now. My code will obviously be shared and our devices are HID compliant, so no need to mess with proprietary drivers.
yeah, except for at least one quirk :) (I wrote the patch to enable the LEDs for the Linux-Kernel :)
On what Operation System are you working btw.?
There already is a HID input module for the Gimp, you can find the source code in the top-level "modules" directory, relevant are the controller_*-files.
We have various input modules, also available is a MIDI input module.
The current architecture unfortunately does not yet allow you to hook into the (paint)-Tools directly, you can only invoke "actions". There are lots of actions and it is easy to e.g. control the opacity.
However, you can not control the pointer position in this way.
Have a look into this, I'd be glad to help you to work on this.
Bye, Simon
Adding SpaceNavigator support
On 1/25/08 6:22 PM, "Simon Budig" wrote:
Hi Ettore.
Ettore Pasquini (ettore_pasquini@3dconnexion.com) wrote:
I work for 3Dconnexion (a Logitech company) and we make 3D input devices. We also care about popular 2D apps that could use the high sensitivity of our SpaceNavigator for panning and zooming. GIMP was under our radar and now we are considering to add support for our devices.
I am new to the GIMP code base so I wanted to ask some questions about the architecture first. What would be the best way (from a pure engineering standpoint) to integrate my code? Meaning, via a plugin or just into the main app? Are there modules for I/O events (to deal with tablets, controllers, etc) that I should start with and expand?
BTW let's not worry about licensing issues now. My code will obviously be shared and our devices are HID compliant, so no need to mess with proprietary drivers.
yeah, except for at least one quirk :) (I wrote the patch to enable the LEDs for the Linux-Kernel :)
On what Operation System are you working btw.?
We would like to support OS X, Windows, and Linux.
There already is a HID input module for the Gimp, you can find the source code in the top-level "modules" directory, relevant are the controller_*-files.
We have various input modules, also available is a MIDI input module.
I also developed a super-minimal library built on top of OS frameworks (HID calls on OS X, Direct Input on windoze) that is able to abstract out a generic N-degrees of freedom device like joysticks or other controllers with more than 2 axes. So basically it gives you a uniform cross platform device class and an API to read its axes/buttons. I didn't implement it for Linux yet. It's BSD licensed. If interested/needed, I can share this. But probably you guys already have something similar.
The current architecture unfortunately does not yet allow you to hook into the (paint)-Tools directly, you can only invoke "actions". There are lots of actions and it is easy to e.g. control the opacity.
Mmmh, not sure I follow here, but like I said, I know nothing about GIMP. Not yet. :)
However, you can not control the pointer position in this way.
That's ok. I was thinking to actually move the image around, not the pointer. Our aim is to ease navigation not access to features. So basically we want to avoid (e.g.) the time you spend by moving the mouse over to the scroll bars, dragging them, and re-center the image where you want it to be. We are thinking that with our device, you don't need to move the mouse away from what you were doing, you can easily pan the image with a nudge on the SpaceNavigator and just keep working.
Have a look into this, I'd be glad to help you to work on this.
Thanks! I'll start looking at it.
Ettore
Adding SpaceNavigator support
Hi,
On Sat, 2008-01-26 at 01:16 -0800, Ettore Pasquini wrote:
That's ok. I was thinking to actually move the image around, not the pointer. Our aim is to ease navigation not access to features. So basically we want to avoid (e.g.) the time you spend by moving the mouse over to the scroll bars, dragging them, and re-center the image where you want it to be. We are thinking that with our device, you don't need to move the mouse away from what you were doing, you can easily pan the image with a nudge on the SpaceNavigator and just keep working.
You should be able to do that using the existing Linux Input module. It's just a matter of configuring it. On Windows there's a module for DirectX events as well. So you should be able to achieve this without any code changes. But of course lots of improvements to the input controller architecture are possible and we are looking forward to your patches.
Sven
Adding SpaceNavigator support
On 1/27/08 1:51 AM, "Sven Neumann" wrote:
On Sat, 2008-01-26 at 01:16 -0800, Ettore Pasquini wrote:
We are thinking that with our device, you don't need to move the mouse away from what you were doing, you can easily pan the image with a nudge on the SpaceNavigator and just keep working.
You should be able to do that using the existing Linux Input module. It's just a matter of configuring it. On Windows there's a module for DirectX events as well. So you should be able to achieve this without any code changes. But of course lots of improvements to the input controller architecture are possible and we are looking forward to your patches.
I played with HAL and the GIMP "input controllers" preferences trying to map my device, but so far I had no luck. The GIMP prefs are indeed beautiful and still give me hope on having this solved with no code at least on Linux. So, after building GIMP I noticed the presence of a "Linux Input" entry under the available controllers. I added that to the Active list and I even saw a "3Dconnexion SpacePilot" entry under the Device list. However when I select that, GIMP tells me the State of the device is "not available: Permission denied". Our evil proprietary driver is not running and AFAIK no process is claiming the device.
from HAL Device Manager: linux.device_file = /dev/input/event6
# lsof | grep -i input | awk '{print $1"\t"$8$9}'
Xorg /usr/lib/xorg/modules/input/synaptics_drv.so
Xorg /usr/lib/xorg/modules/input/mouse_drv.so
Xorg /usr/lib/xorg/modules/input/kbd_drv.so
Xorg /dev/input/mice
Xorg /dev/input/event9(deleted)
hald-addo /usr/lib/hal/hald-addon-input
hald-addo /dev/input/event5
hald-addo /dev/input/event4
hald-addo /dev/input/event3
hald-addo /dev/input/event1
hald-addo /dev/input/event0
lt-gimp-2
/home/ep/svn/gimp/builds/main/lib/gimp/2.0/modules/libcontroller_linux_input
.so
In HAL, I also noticed the default is that "input.mouse" is actually added by default to the info.capabilities list of our device, so I can actually move the mouse pointer with it. Could that be it, interfering with GIMP? (BTW I don't want to move the mouse pointer.)
So I went ahead and created my own .fdi file, first just adding input.joystick to the list (made sense) but no changes. Then I removed "input.mouse" and had input.joystick only, however in this case GIMP doesn't see the SpacePilot device entry anymore. Why?
If anybody can shed some light on this I'd really appreciate it, it seems like everything is already there (if only I could manage to "trigger" it).
Thanks.
Ettore
Adding SpaceNavigator support
On 2/26/08 7:52 PM, "Ettore Pasquini" wrote:
So, after building GIMP I noticed the presence of a "Linux Input" entry under the available controllers. I added that to the Active list and I even saw a "3Dconnexion SpacePilot" entry under the Device list. However when I select that, GIMP tells me the State of the device is "not available: Permission denied".
It turned out to be a couple wrong assumptions on my side. First the linux device file /dev/input/eventN was for some reason not readable by anyone but root. Second, I realized I had built GIMP with NO HAL support. :)
After fixing that I was able to map the device actions and it works! Panning is pretty good, although there is no acceleration (moving the device hard or soft makes no difference). One other problem is that event values are not scaled on a per-type basis: e.g. Zoom is too fast and it's uncontrollable. Button mapping work perfectly.
Ideally every "increase/decrease" parameter should have a related scale/speed adjustment setting. I was thinking to add a 3rd column to the Select Event Action panel, unless somebody has a better idea.
Ettore
Adding SpaceNavigator support
Hi,
On Wed, 2008-02-27 at 19:16 -0800, Ettore Pasquini wrote:
It turned out to be a couple wrong assumptions on my side. First the linux device file /dev/input/eventN was for some reason not readable by anyone but root.
I usually fix this by adding a udev rule that changes the device permissions for all usb input devices to allow the group "plugdev" to access the device.
After fixing that I was able to map the device actions and it works! Panning is pretty good, although there is no acceleration (moving the device hard or soft makes no difference).
Does moving the device hard or soft make a difference in terms of what input events the Linux kernel delivers?
Sven
Adding SpaceNavigator support
On 3/2/08 8:46 AM, "Sven Neumann" wrote:
On Wed, 2008-02-27 at 19:16 -0800, Ettore Pasquini wrote:
It turned out to be a couple wrong assumptions on my side. First the linux device file /dev/input/eventN was for some reason not readable by anyone but root.
I usually fix this by adding a udev rule that changes the device permissions for all usb input devices to allow the group "plugdev" to access the device.
Yep, that's pretty much what I did. I added a post to our forum:
http://www.3dconnexion.com/forum/viewtopic.php?t=1917
Does moving the device hard or soft make a difference in terms of what input events the Linux kernel delivers?
I do receive different values, however this doesn't make any visible difference on the screen: the view is translated always with a constant speed. It basically behaves like a switch, "move or not".
Ettore
Adding SpaceNavigator support
Sven Neumann (sven@gimp.org) wrote:
On Wed, 2008-02-27 at 19:16 -0800, Ettore Pasquini wrote:
After fixing that I was able to map the device actions and it works! Panning is pretty good, although there is no acceleration (moving the device hard or soft makes no difference).
Does moving the device hard or soft make a difference in terms of what input events the Linux kernel delivers?
The "value" element of the struct input_event may contain values with an absolute value > 1.
I found it a bit tricky to work with these events. On one hand it absolutely makes sense that the SpaceNavigator delivers relative events, at least for the intended purpose. But this means that the amount of pressure you apply controls the *rate* of the events, which is a bit tricky to measure.
For me it would be easier to get absolute events from the SpaceNavigator and - if needed - convert them to a series of relative events myself. The other way around is not as trivial I think.
Bye, Simon
Adding SpaceNavigator support
Ettore Pasquini (ettore_pasquini@3dconnexion.com) wrote:
On 3/2/08 8:46 AM, "Sven Neumann" wrote:
On Wed, 2008-02-27 at 19:16 -0800, Ettore Pasquini wrote:
It turned out to be a couple wrong assumptions on my side. First the linux device file /dev/input/eventN was for some reason not readable by anyone but root.
I usually fix this by adding a udev rule that changes the device permissions for all usb input devices to allow the group "plugdev" to access the device.
Yep, that's pretty much what I did. I added a post to our forum:
For helix I have prepared the following udev rule:
KERNEL=="event[0-9]*", ATTRS{name}=="3Dconnexion Space*", SYMLINK+="input/3d-nav", MODE="0666"
This matches the USB device name against "3Dconnexion Space*", which should cover all 6DOF devices from 3Dconnexion. It also symlinks that device to a fixed position so that programs can make assumptions about the device name without probing the linux input layer.
Maybe this is useful for you.
Bye, Simon
Adding SpaceNavigator support
On Tuesday 04 March 2008 11:27:52 Simon Budig wrote:
I found it a bit tricky to work with these events. On one hand it absolutely makes sense that the SpaceNavigator delivers relative events, at least for the intended purpose. But this means that the amount of pressure you apply controls the *rate* of the events, which is a bit tricky to measure.
There's time included with events (that needs a bit of critical eye, since X events time resolution sucks), but difference of timestamps should give you the rate you need...
Adding SpaceNavigator support
Hi,
On Tue, 2008-03-04 at 17:05 +0200, Alexia Death wrote:
There's time included with events (that needs a bit of critical eye, since X events time resolution sucks), but difference of timestamps should give you the rate you need...
We aren't talking about X input events here but raw Linux input events.
Sven
Adding SpaceNavigator support
Hi,
On Tue, 2008-03-04 at 10:27 +0100, Simon Budig wrote:
Does moving the device hard or soft make a difference in terms of what input events the Linux kernel delivers?
The "value" element of the struct input_event may contain values with an absolute value > 1.
It should be possible then to change the code to take this into account. I am not sure though how we can handle devices that send these events with a value of 1. If we interpret this the same way that would result in a very small movement then.
Sven
Adding SpaceNavigator support
Hi,
sven@gimp.org (2008-03-04 at 2020.46 +0100):
On Tue, 2008-03-04 at 17:05 +0200, Alexia Death wrote:
There's time included with events (that needs a bit of critical eye, since X events time resolution sucks), but difference of timestamps should give you the rate you need...
We aren't talking about X input events here but raw Linux input events.
Could someone explain the adventages of not using the same path than with tablets and taking a shortcut? For the moment, I have seen disadventages like having to play with permissions and losing X11 remote capabilities.
GSR
Adding SpaceNavigator support
Hi,
On Tue, 2008-03-04 at 22:23 +0100, GSR - FR wrote:
We aren't talking about X input events here but raw Linux input events.
Could someone explain the adventages of not using the same path than with tablets and taking a shortcut?
The only advantage is that you can access a device that is not fully supported as an X input device. If there was full support, we would not have to use this kludge.
Sven
Adding SpaceNavigator support
Hi,
sven@gimp.org (2008-03-05 at 0849.30 +0100):
We aren't talking about X input events here but raw Linux input events.
Could someone explain the adventages of not using the same path than with tablets and taking a shortcut?
The only advantage is that you can access a device that is not fully supported as an X input device. If there was full support, we would not have to use this kludge.
Then the next question is what part is missing for "full support", as examples like http://www.fox-toolkit.org/news.html seem to point it is supported to some level.
GSR
Adding SpaceNavigator support
Hi,
On Wed, 2008-03-05 at 19:47 +0100, GSR - FR wrote:
Then the next question is what part is missing for "full support", as examples like http://www.fox-toolkit.org/news.html seem to point it is supported to some level.
Support for Linux Input devices in GIMP has been around long before X.org got support for USB HID devices. Feel free to rewrite it. But as long as that hasn't happened, it is better than nothing, a lot better.
Sven
