[RFC] XInput hotplugger daemon

[Magnus Vigerlöf]

On söndag 16 mars 2008, Daniel Stone wrote:
> Hi Magnus,

Hello Daniel,

> On Thu, Mar 13, 2008 at 09:53:37PM +0100, Magnus Vigerlöf wrote:
> > So I've realised that there is a need for another way of hotpluging the
> > connected devices than through the internal HAL-support in the Xserver,
> > an external hotplugger daemon. This has been mentioned as a possible way
> > to solve hotplugging in some posts here, but my searches for someone
> > making a program like this has turned up empty.
>
> Well, at the moment, this is the case.  But, bear with me ...
>
> I've been thinking about this for a little while.  Basically, at the
> moment, the only real way we have of expressing anything is through a
> combination of DeviceIntRec, and DeviceInfoRec/et al in XFree86.  We
> create fake devices, pass them around, and everything has to always be
> on inputInfo.devices.
>
> What if we dropped that? Ideally, we'd be able to punt an fd (or, if we
> depend on it everywhere, a HAL UDI) to a driver and say 'hey, do you
> know anything about this?'.  From there, it's free to create as many
> devices of as varied description as it likes.  Ideally, we'd also
> flatten the input infrastructure at the same time, and basically punt
> everything that we do for input now in the DDX down to the DIX, as it's
> more or less identical.  This would make things like NIDR/DIDR semantics
> a lot easier, as we can have simple policy callouts, rather than
> irritating abstractions we can't see through.
>
> So, with this, the Wacom driver would take an fdi, device name,
> whatever, and open it up, see that it's a Wacom tablet, and add all
> three devices.  Does this seem sensible?

I wouldn't mind a more simple structure of the InputDevices inside the server, 
but I don't see it will do much difference to the hotplugging process as 
such.

My main problem is that somewhere in the process we're bound to have some user 
configuration that we need to take into account when we're adding the 
InputDevices. For a keyboard this can easily be managed after the device has 
been added as you always use the keyboard as a whole. You never want to 
divide a keyboard into 'main-keyboard' and 'numeric-keypad' which would be 
two separate InputDevices, right? There's not a point in doing it as we're 
able to identify each key uniquely.

As I see it pointing devices are a bit different. Mice and other devices that 
only report relative movements can be handled just as the keyboards are 
handled, but the ones with a defined value range? (for now only X&Y matters, 
but I wouldn't be surprised to see that this might change)

The wacom driver allow the user to define how to translate the active area of 
one tablet into one or more InputDevices. First by branching on type 
(stylus/eraser/cursor/pad), second by branching on the serial id of the tool, 
and third by branching on where in the active area the tool is used. I don't 
see pushing this kind of configuration down to the kernel as a way to solve 
this for the XServer.

The number of types can easily be defined by the tablet vendor & model, but 
the second one can only be configured by the user as can the third one. So 
you see, the user config here is a vital part of defining the resulting 
InputDevices. It would also mean that the InputDevices could change as users 
log out/in as well... Worst driver possible? Maybe.. ;)

So for me the natural way of handling hotplugging at the moment is:
HAL->daemon->XSever

Where the daemon would be where we put the user configuration and thereby the 
decision which InputDevices to add. Start it when [gkx]dm starts so we can 
handle hotplugging devices while noone is logged in. Then restart it as the 
user as a part of the X initialization process (i.e. calling the scripts 
in /etc/X11/Xsession.d/*). A nice thing with this approach would be that the 
devices could be reset by the daemon that is started when [gkx]dm is started 
when the user log out.


However, if the XServer would expose the internals, which drivers are loaded, 
currently defined InputDevices, allow a configuration tool to manipulate all 
aspects of the definition of them (add, remove, ...) over a well defined 
protocol I guess that would make me change my mind. But I do believe in 
keeping that kind of complexity outside the server and only expose a simple 
API (as we have today).

> > So what do you think? I need something that solves the hotplugging issue
> > with my tablet, and I think this is one way to solve it.
>
> The daemon needs to be done anyway, basically just for settings.  The
> FDI needs to set everything basic up with the systemwide preferences,
> but then there's bits like 'oh yes, Dave uses the trackball
> left-handed', which you really want to be per-user.
> gnome-settings-daemon already does this today with keyboard layouts, so
> it's pretty trivial to just have all these settings and whathaveyou
> remembered in the desktop environment.

I'm afraid I can see much more complex 'add-ons' than 'oh yes, Dave uses...' 
which would make the gnome-settings-daemon et al inadequate to handle the 
configuration I want...

For me that manifest itself in the following:
I have a laptop with a wide-screen display. My tablet is not wide-screen (5x4" 
actually). This leaves me with a 1cm thick border at the bottom if I want to 
have the right aspect ratio between the tablet and screen. Now, I want to use 
this area in some way. Mmmm... Let's define some buttons that can help me 
when I work, shortcuts for the most common commands. How am I going to define 
this with the current daemon that exists for the keyboards and mice?

Basically, this is what I want to be able to do in an intuitively and 
user-friendly way when we're done here...

> So yes, I think the idea's completely sound.

Then the only questions are; where should it be and what should it do :)

Cheers
  Magnus

[1] http://lists.freedesktop.org/archives/xorg/2008-February/032659.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.x.org/archives/xorg/attachments/20080316/109d443e/attachment.pgp>