X.Org devd backend for input devices (was: [CFT] Update of xorg libraries and MESA)
Jean-Sébastien Pédron
dumbbell at FreeBSD.org
Tue Sep 17 19:44:54 UTC 2013
Le 16/09/2013 13:53, Vitaly Magerya a écrit :
> I'm actually using a devd backend I wrote a few months ago
> (which avoids the mentioned issues), but it's rather different
> from yours (more intrusive that is):
This first devd patch is incomplete. As you mentionned, it doesn't fill
all the informations which could be useful in Inputclass sections in
xorg.conf.
But before speaking about that, I believe we have a more important issue
to fix: the console and Xorg can't open input devices simultaneously. At
least, on my computer, the patch doesn't work because when X starts (or
when I plug a new keyboard), it fails to add any keyboard because the
console grabbed it. Same for mices if moused is enabled. Therefore, I
have questions about your devd backend:
o do you use kbdmux and/or moused?
o is Xorg able to open devices?
On my computer, Xorg can't do that because, keyboard devices are already
opened by kbdmux (which is then used by the console), and mices are
opened by moused (because I want to be able to have a mouse in console
for instance); Xorg uses /dev/sysmouse in this case.
I just checked on Linux: it appears that Xorg opens /dev/input/*
devices. But when I vt-switch and check again: everything is closed. If
I vt-switch back to Xorg, all input devices are reopened. I see nothing
about that in the udev backend, thus I guess it's handled in Xorg, no
matter what backend is used.
We could achieve a similar behavior by detaching keyboards from kbdmux
and stopping all moused when Xorg starts (eg. do it from
config_devd_init()) and reattaching keyboards and starting moused again
when Xorg exits (config_devd_fini()). There's the problem of
vt-switching, because even if Xorg closes devices, we still need to
re-associate them with the console. Maybe Xorg provides a hook when
doing a vt-switch or setmaster/dropmaster, which we can use to to this.
I still need to look into that.
I very much like your approach of using an additionnal script executed
by devd. The C code in X.Org could be minimal and the script could be
installed by the port. The script would just prepare simple formatted
one-line messages (containing all properties) and send them to any
running X servers.
Regarding the restart of devd, I don't think there's an issue here,
because backends should check if an input device is already present in
X.Org before adding it again. There's no need to maintain a regular file.
> The open problems here are:
> 1) what should happen if multiple X instances are running?
The problem is the same than with X+console. If X #1 closes the devices
when vt-switching and X #2 reopens them, then it's fine. However, for
hot-plugged input devices, I don't know if one can specify a flag to
ignore open failure, or if the not-currently-master X servers re-probe
devices when becoming master again, because only one will be able to
open them. This too needs more research and study of udev backend.
--
Jean-Sébastien Pédron
More information about the freebsd-x11
mailing list