[Xgl/Xegl] Input Devices
evan at coolrunningconcepts.com
evan at coolrunningconcepts.com
Tue Jul 19 18:27:43 PDT 2005
Hi Dan,
I can't really give the most informed opinion on this, but I can give you my
view from an end-user.
I normally use a wacom graphics tablet as my main mouse (with Xorg). I like not
having to worry about batteries and a charger and extra power cables like my
logitech, and the resolution of the wacom mouse is just as good - or appears to
be for my uses. Of course, being able to grab the stylus and use it with Gimp
is certainly an added bonus.
However, if I use /dev/input/mice, the wacom doesn't always perform properly.
If I use it exclusively, the wacom goes into its IMPS compatibility mode and
works fine, but you don't get XINPUT extensions. If I use the
/dev/input/eventX exclusively, it works in its native mode. I can't use both
as they seem to conflict, so a second mouse can't use /dev/input/mice, but
rather its specific device node.
Now, if for some reason, the mouse gets unplugged, and replugged, it can assign
a new event device - evidently it doesn't get the unplug event as quickly as
the plug event. The config file requires that the device be named
specifically, so when it changes, you aren't likely to get it working without
taking down X.
I've noticed that all you have to do is look in /proc/bus/input/devices and all
input devices are nicely described along with what device nodes they are
connected to. If X would use this information instead of having the user
statically define the device entries in a file, then quit a bit of user issues
would be resolved. As to how X would know that a new device was plugged or
unplugged so it could consult /proc/bus/input/device again for the new
settings, I don't know. I guess HAL would be in charge of that? I don't know
how non-Linux systems would work, but I think if the information is there, it
should be used, as there can always be a fallback for systems that don't have
HAL and such.
Just my 2 cents on something related that I've been wishing for quite some time.
-- Evan
More information about the xorg
mailing list