[RFC] XInput hotplugger daemon
Magnus.Vigerlof at home.se
Sun Mar 16 10:42:31 PDT 2008
On söndag 16 mars 2008, Daniel Stone wrote:
> Hi Magnus,
> 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
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:
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 :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the xorg