[RFC] XInput hotplugger daemon

[Daniel Stone]

On Sun, Mar 16, 2008 at 06:42:31PM +0100, Magnus Vigerlöf wrote:
> On söndag 16 mars 2008, Daniel Stone wrote:
> > Hi Magnus,
> 
> Hello Daniel,

Hej,

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

It's not a silver bullet, but it would help if we restructured to let
the driver decide how to do the devices, rather than 1:1, no?

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

Right.

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

Urgh.  I guess the problem is that you then add multiple paths into the
X server, which is bad.

You say that it splits on tool IDs.  What about if we provided subdevice
IDs? This could be then used for either the tool or area, with a
descriptor attached, and then the only configuration you need is to set
up the separate areas.  You don't need any separate daemon to handle
hotplugging while not logged in, as you've just added the device and
you're assuming every tool is a separate subdevice for now.  gdm
probably doesn't care.

Configuring the separate areas would be reasonably easy, too: we already
have AbsArea providing a poor approximation of this.

Does this sound reasonable? It's still user-guided, but we still always
keep fully automated device addition/removal.  Of course the user can
always dynamically enable and disable devices and configure them, but we
stick to the principle of 'only way for devices to be added and
removed'.

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

This isn't really gnome-settings-daemon territory: sounds like you want
to configure both CRTCs and viewports with RandR, then have some kind of
menu app (or whatever) running in the space where you scan out your
tablet but not your screen.  This punts a significant amount of
complexity out ...

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

It's a somewhat contrived usecase (most people who aren't X/Wacom
hackers would probably be fine with just losing the space, to be honest),
but I think it's still doable.

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg/attachments/20080316/406d8939/attachment.pgp>