Support for SpaceNavigator

[Håvard Tørring]

Hello,

I have a 3dconnexion space navigator that I would love to be able to use to pan and zoom the images in gimp. Googling around, I have found a few references to the topic, but as far as I can see, there's no solution yet. The following link describes how to use the input controller module of gimp to get som basic support.

http://www.3dconnexion.com/forum/viewtopic.php?t=1917&start=0&postdays=0&postorder=asc&highlight=

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?

- 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.

Thank you for your time.
Havard Torring

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Simon Budig]

Håvard Tørring (htoerrin@...) 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
--
              simon@...              http://simon.budig.de/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Alexandre Prokoudine]

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
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Håvard Tørring]

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.

The actual scrolling is performed by view_scroll_horizontal_cmd_callback in view_commands.c. At this point I can't see how to actually access the value of the event.

The initialization of the callback functions seemes to be done in view-actions.c

So the problem seemes to be that the scrolling functions as they are implemented does not support any values. Are there any way I can access the value of the event from the scrolling function.

Are there any actions that supports values that I could use as a template or example to better understand what's going on?

Havard Torring

On Mon, Jun 15, 2009 at 10:39 PM, Simon Budig <simon@...> wrote:

Håvard Tørring (htoerrin@...) 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
--
             simon@...              http://simon.budig.de/
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Håvard Tørring]

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?

Havard Torring

On Sun, Jun 28, 2009 at 11:49 PM, Håvard Tørring <htoerrin@...> 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?

Havard Torring

On Mon, Jun 22, 2009 at 11:27 PM, Sven Neumann <sven@...> wrote:

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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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



_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Håvard Tørring]

Hi,

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.

Havard

On Mon, Jun 29, 2009 at 11:11 PM, Sven Neumann <sven@...> wrote:

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

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Sven Neumann]

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


_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer