X.Org devd backend for input devices

[Vitaly Magerya]

On 09/17/2013 22:44, Jean-Sébastien Pédron wrote:
> 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.

That sounds about right. Xorg can't grab /dev/kbd* at all; it
can grab /dev/psm* only if moused is not running, in which case
mouse doesn't work in console.

> Therefore, I have questions about your devd backend:
>      o  do you use kbdmux and/or moused?
>      o  is Xorg able to open devices?

The way I currently do it myself is this:
1) sysmouse mouse is added statically, from xorg.conf
2) syscons keyboard is added the same way
3) moused feeds psm0 into sysmouse
4) USB mice and tablets (both uhid; I don't use ums) are added
   by the backend automatically; these do not go through moused,
   and thus are unavailable on the console

(#1 and #2 can be done automatically, I just didn't yet bother to).

In short no, as far as I know, if you want your mice and keyboard
to work in both the console and X, X will have to work with
sysmouse/syscons aggregators, and not try to grab each device
separately. That is not good enough in your use case, right?

And just to clarify: HAL doesn't have any magic to fix that
either, correct? I.e. if you're running moused, X will only see
one combined mouse device (syscons), not separate ones.

> 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.

That is interesting, I'll need to take a look at that.

> 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()).

That seems prone to failure; if Xorg segfaults, will moused stay down?
This needs further investigation.

> 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.

Exactly.

(This will also allow e.g. webcamd to autoadd it's input devices
to X with no new code on Xorg side).

> 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.

I'm not sure we're on the same page here, but this point can be
discussed later.

> > > 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. [...]
> This too needs more research and study of udev backend.

Yup, let's take a look at the Linux side of things.