On Sat, Jan 21, 2012 at 07:28:06PM +0100, Cedric Sodhi wrote: > I would like to discuss the topic of precedence. Currently, XF86/I/W > manages multiple "subdevices" of a single device internally. > > That solution does not seem very good for the long term. > > Ben Tissoires once told me about a vision in which all these problems > should be rectified, somewhere, somehow, but as of today, I have not > seen or heard any details. > > It should be possible to give any device precedence over another. > > The best example is perhaps the situation I'm in, where the touchscreen > and the digitizer are governed by two distinct devices. > > Well, you can't apply that concept to just every input device. Whatever > layer manages that kind of precedence has to know when a pointer is > "active" and therefore possibly "grabs the master". In the case of a > pen, that "activity" is apparently indicated by the pen being in the > proximity. > > But so far, "promiximity" appears to be a wacom-specific concept.
huh? proximity has been in the X input protocol for ages and there are several other drivers that use it (evdev, for example). wacom devices are special in that the kernel driver doesn't separate the devices out into multiple distinct ones (all for a reason). so we have to multiplex inside the driver. that's really what makes the wacom driver different. most currently wacom-specific features could be used in other drivers too. > Therefore my question: Is there anything in place which could allow > generalizing that concept onto a layer which allows to apply it to an > arbtirary group of devices, possibly not even managed by wacom? yeah, it's called X. clients usually don't have to care what actual device is running, they just see X devices and use those. beyond that, generalising gets a bit difficult. you could argue for a libinputmodule to get all the commonly used functionality into a library that multiple drivers use. But the inertia for that is quite big, you'd still need some compat code for the time being and it's a rather large and boring task to even get started. Plus, then you have 2 ABIs you need to worry about instead of just one. But a libinputmodule is the most sensible way for many of the options we currently support. > PS: > In the end, it is my opinion that the XF86/I/W has, forced by the > circumstances under which it is written, drifted into the generally > wrong direction, incorporating all types of feature it has come accross, > like a huge snowball absorbing all kind of matter it rolls over. > > Many of the features which the wacom currently has should be made > available on the XI layer. yep. and we've been making steady progress at moving stuff out of the driver. many of the things that used to be in the driver are now handled in the server. Cheers, Peter ------------------------------------------------------------------------------ Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 _______________________________________________ Linuxwacom-devel mailing list Linuxwacom-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/linuxwacom-devel
