[PATCH RFC] Add a FOCUS_FORCE flag to the device's focus class

[Peter Hutterer]

On Tue, Jan 17, 2012 at 11:06:55AM -0500, Jennifer Elaan wrote:
> It's been a while since I've looked at this code, so I might not be
> following entirely, but if I'm reading it correctly, it would appear that
> it sets the event type in such a way that the event will not be interpreted
> as a pointer motion?

not quite, the event itself is unmodified. only the delivery is adjusted so
instead of the window at the x/y coordinate the event is delivered to the
focus window (if any) or the virtual core pointer's (VCP) sprite window (if
floating). Judging from some tests I ran on RHEL5, this is how XI devices
used to behave.

For an application, it simply means that for each device it wants to
control, it should set the input focus via XSetDeviceFocus to the window of
choice. Again, afaict this is the traditional XI behaviour.

The hardcoded binding to the VCP is a bit unfortunate, but we could
potentially expose this via a new device class in XI 2.3 to manipulate it.
Not something too urgent, I suspect.

Either way, this should fix the issue you've been seeing (and a
somewhat related bug I've been working on).

Cheers,
  Peter

> 
> If so, this is exactly what will be required to add SpaceNavigator support
> directly as an XInput driver, rather than using a special management
> daemon.  The use case that needs support is if two 3D applications are open
> at once, whichever one has keyboard focus should receive extension valuator
> events, rather than pointer events, from the SN.  Generally this is used to
> manipulate the 3D camera inside the application, not the pointer.
> 
> Right now, SecondLife opens the device directly as a joystick, and Blender
> requires the use of a special daemon.  Making them share nicely is
> effectively impossible right now.  There may be other applications of this
> device that I am not aware of, but these two alone demonstrate the current
> problem.
> 
> There are other similar input devices still on the market, like jog wheels,
> etc, which also are intended to send numerical valuator inputs which are
> not pointer movement events.
> 
> On Mon, Jan 16, 2012 at 11:27 PM, Peter Hutterer
> <peter.hutterer at who-t.net>wrote:
> 
> > Some devices should not use a traditional pointer-focusing model but
> > instead
> > should be controlled by the client at all times. One example are tablets
> > that are bound through the GDK map to window option. Once focused, the
> > tablet events should always go to the focus window.
> >
> > Currently, devices only send pointer events to the window at the sprite
> > location. This behaviour was introduced in a88386ee277d136caaae
> > and breaks how XI 1.x devices used to be handled.
> >
> > A device that uses forced focus will always either deliver to the focus
> > window, or to the sprite window if the focus is PointerRoot. If the device
> > is a floating slave device, the VCP determines the sprite window.
> > Forced focus devices are listed as IsXExtensionDevice, this best emulates
> > the original behaviour for XI 1.x clients that need it.
> >
> > A device can be enabled as such a device through the ForceFocus option in
> > the config file or snippet. This is a permanent option and cannot be
> > changed
> > at runtime.
> >
> > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> >