From: Magnus <wi...@bi...> - 2006-08-31 21:38:42
|
Hi, For people who'd like the point to be made in the first five lines: I don't think (anymore) that support for changing the tablet model is a good idea for a driver to Xorg 7.0 (and maybe other X-servers). Why not? Read on... During the last weeks I've been looking through the source code of both linuxwacom and Xorg, and also the documentation to Xorg. I've come to realize the change that my module (wacomproxy) requires (the ability to change the properties of the defined XInput devices at runtime) might not be suitable for the current Xorg implementation (7.0, is this true for XFree86 as well?). This 'problem' would be the same as when you would switch between two different tablets. The problem as I can see it is the change in the connected HW and the need to propagate these changes to the X-applications. As I understood it, neither Xorg nor the applications are prepared that something like this should happen and therefore can't deal with this in a good manner (if at all). Upcoming releases of Xorg are addressing the addition/removal of XInput devices but they are talking of a new version of the XInputSpec (new functions; addition, removal, etc) (and there's a very, very small note that a change of the module ABI might be of interest). They also mention problems with the GTK-framwork regarding removal of XInput devices. See also http://wiki.x.org/wiki/XInputHotplug So considering this, is it really a good idea to support changes of the tablet properties in the driver that I started with and that has been included in the -dev-branch? I'd hate myself if I managed to push Ping into a corner of sticky goo that I'm afraid that the changing tablet properties is... Having true hotplugging of the XInput devices are of course the way we all want it, but trying to make something like that today with an X-server that does not support it... I'm thinking of making changes in my module to lock it to only one tablet model (the first model connected or a specific tablet defined as a module param) due to this realization. Comments are appreciated. Thanks for listening to random thoughts written in the night Magnus |