xorg-server/*bsd: moving from hal support to devd support?

[Cyril Brulebois]

Hi Warner,

Warner Losh <imp at bsdimp.com> (14/02/2011):
> I'm mentioned this several times now: Get me a spec for what Linux
> udev provides, and what services are needed, and I'll make a
> compatible implementation on FreeBSD.

as far as X is concerned, see Dan's reply to my first mail:
  http://lists.debian.org/debian-bsd/2011/02/msg00120.html

I think we really don't care how udev works, we just need to gather:
 - devices available when X starts,
 - devices updated while X is running.

What follows was performed on a GNU/kFreeBSD system in QEMU.

For now, I tried to print all variables mentioned in devd.conf(5), and
used “usb_add mouse”/“usb_del 0.2” in the QEMU console
(adding/removing an USB mouse). That notified me about ugen0.2 getting
ATTACHED and DETACHED. Since I'm pretty unfamiliar with FreeBSD, I
couldn't link that to the according /dev/ums0 being created/deleted.

Since I wanted to try and play with hotplug anyway, I wrote a tiny
daemon to perform input bookkeeping (inputbk), which does:
 - list all devices through libdevinfo which seem to be input devices
   (for now I matched on the drivername, being one of: atkbd, psm,
   ukbd, ums; uhci should probably be added, but I coudln't check
   myself);
 - sleep one second (which could easily be replaced with waiting for a
   devd ATTACH/DETACH event);
 - list all devices again, and print added/deleted devices.

Then in the xorg-server sources, I started a config/inputkb.c file, and
added a device based on the information I printed from the inputbk
daemon (which I hardcoded to check quickly how it went), which gave me
X working without configuration, and without hal.


Now, I'm wondering where to go from here. Given what I wrote up to
now, my next move to check hotplug works properly:
 - make inputbk perform a blocking open on a fifo for writing,
 - make it wait for a reader to write a listing of devices,
 - then make it loop and only write updates there.

On the X side, we would be doing:
 - read the initial listing, adding devices as appropriate,
 - add this fifo to the big select() of X, using a callback which
   would trigger device addition/removal as notified through the
   socket by inputbk.


In a perfect world, we should be able to have several readers, since
we might have some X instances running in parallel, so the named pipe
approach is probably a bad idea (then, using a socket and adding a few
lines of code would buy a daemon handling several clients). Also, I'd
be happy to see the above-mentioned bookkeeping go in some other
place. AFAICT, devd is appropriate for change notifications, but I'm
not sure its purpose is also to keep a list of available devices.

What do you think?

KiBi.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.x.org/archives/xorg-devel/attachments/20110215/9c93d003/attachment.pgp>