Håvard Tørring (htoerrin@gmail.com) wrote:

Hello,

I have a 3dconnexion space navigator that I would love to be able to use to pan and zoom the images in gimp.

Yay, I have one of these as well. Please hack on that :-)

The problem with this approach is that gimp ignores the value of the events, making it unusable. Browsing around the source code, I have identified that the events from the navigator are correctly identified in controller_linux_input.c, but when mapped to actual events, such as panning, the values from the controller are ignored, and the panning is performed with a fixed pixelcount per event. So my questions are as follows:

- Are there any ongoing work with this controller that I should be aware of?

I am not aware of any current work in that area.

- Are there someone that could give me a brief description of how the events from the input controller are communicated through the software? I have been unable to identify where in the code the calls to the panning and zooming functions are generated.

The linux input controller module has a mapping, that maps events to so called "actions", which are the same thing that e.g. get attached to the menu. The mapping from event to action happens in app/widgets/gimpcontrollerinfo.c in gimp_controller_info_event, which - if it has a mapping - emits an "event-mapped" signal. This in turn gets handled in app/widgets/gimpcontrollers.c, there you also see the logic how events with values are handled. Basically the assigned action needs to be an GIMP_ENUM_ACTION for the reported value to have an effect.

It is perfectly possible that the actions used to scroll the view are not ENUM_ACTIONs and need fixing for this to work as expected.

I hope this helps, Simon

Hi,

On Mon, 2009-06-15 at 20:30 +0200, Håvard Tørring wrote:

The problem with this approach is that gimp ignores the value of the events, making it unusable. Browsing around the source code, I have identified that the events from the navigator are correctly identified in controller_linux_input.c, but when mapped to actual events, such as panning, the values from the controller are ignored, and the panning is performed with a fixed pixelcount per event. So my questions are as follows:

- Are there any ongoing work with this controller that I should be aware of?

Not that I know of. Logitech sent me one of these devices a while ago and promised they would contribute code to use it in GIMP. We fixed some issues with the Linux Input code then, but never really finished this. And there hasn't been any code contributed from Logitech either.

- Are there someone that could give me a brief description of how the events from the input controller are communicated through the software? I have been unable to identify where in the code the calls to the panning and zooming functions are generated.

The events are mapped to actions. The actions for zooming and panning are defined in app/actions/view-actions.c and app/actions/view-commands.c. Unfortunately the current framework doesn't allow to do this in a way that would make the device usable. But I am sure that this can be improved.

Sven

On Tue, Jun 16, 2009 at 12:48 AM, Sven Neumann wrote:

Not that I know of. Logitech sent me one of these devices a while ago and promised they would contribute code to use it in GIMP. We fixed some issues with the Linux Input code then, but never really finished this. And there hasn't been any code contributed from Logitech either.

The Logitech guy who was active (in this list too) actually left the company shortly after that to start his own one from what I remember.

Alexandre

On Mon, 2009-06-22 at 21:41 +0200, Håvard Tørring wrote:

OK, I'll give it a try,..

I have a little problem getting into the code. I am new to the gtk environment, the event handling and much of the gui stuff, so unfortunately the learning curve is pretty steep. Anyhow, this is what I have found.

As far as I can see, the following line in gimpcontrollerinfo.c emits the signal that initiates the scroll function

g_signal_emit (info, info_signals[EVENT_MAPPED], 0, controller, event, action_name, &retval);

event contains the value, so I would be happy if I could pick up this value later on, when the actual scrolling is performed.

This signal is then handled in gimp_controllers_event_mapped() as found in gimpcontrollers.c. Here the event is translated into the activation of a GtkAction. As you can see the event's value is multiplied by 1000 and passed with the action. Later this value is then passed to action_select_value() where it is divided by 1000 again and interpreted as an absolute value normalized to the scroll-bar range. This is all a rather bad hack. To some extent it works for controllers that send absolute events. The device you are trying to use there sends relative events values though and all the assumptions that this code relies on break badly. This will need a clever redesign.

Sven

Hi,

On Mon, 2009-06-29 at 22:58 +0200, Håvard Tørring wrote:

I am testing this with panning by mapping events from 3dconnexion to view-scroll-up/down/left/
right. In the mentioned function, the if test fails on GIMP_ENUM_ACTION (action)->value_variable returning 0. I assume this means that the view-scroll actions does not take any value. Is this correct? Are there any panning actions I could use that accepts value?

I don't think that any suitable actions exist.

Sven

Hi,

On Sun, 2009-08-23 at 15:52 +0200, Håvard Tørring wrote:

It took me a little while to dig through the various layers, but I think I am approaching something that might end up as useful. One problem is that the events that are generated are qued up if the actions does not perform fast enough. The SpaceNavigator outputs a lot of events, and especially the zooming actions are slow. This means that with just a brief touch of the spacenavigator, the zoom level jumps from minimum to maximum.

I think that it does not make any sense to que up the events from this device. Are there any way I can prevent this? Is there any way to know if there are pending actions? This could be used to avoid sending new actions as long as the previous ones are still pending.

I don't think the actions are queued up. What is more likely is that the events are queuing up. So what should be done is implementing event compression on the incoming events. Instead of reading them one-by-one and creating an action from every incoming event, the linux-input module should read all the available events from the queue and compress them. If a number of relative events on the same axis are following each other, this can be combined into a single relative event with the sum of all event values. From a series of absolute events all events but the last can be discarded.

For illustration, here's some code from a different project that does something similar (though somewhat simpler):

gsize bytes_read = 0; struct input_event buf[8];

if (g_io_channel_read_chars (io, (gchar *) &buf, sizeof (buf), &bytes_read, NULL) == G_IO_STATUS_NORMAL) {
const struct input_event *event;

const gint num = (bytes_read / sizeof (struct input_event)); gint value = 0; gint i;

for (event = buf, i = 0; i < num; event++, i++) {
if (event->type == EV_REL && event->code == REL_X) value += event->value; }

if (value) ; // process the compressed event here }

Sven