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

[Dan Nicholson]

On Tue, Feb 15, 2011 at 8:28 AM, Cyril Brulebois <kibi at debian.org> wrote:
> 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?

Just to give background about how the udev backend operates with
libudev, here's the API reference for libudev:

http://www.kernel.org/pub/linux/utils/kernel/hotplug/libudev/

What happens is that a udev_monitor is created and the fd is added for
polling and handlers are registered. In
config/udev.c::config_udev_init():

    RegisterBlockAndWakeupHandlers(block_handler, wakeup_handler, NULL);
    AddGeneralSocket(udev_monitor_get_fd(udev_monitor));

Once the events are received, the udev_device API is used to determine
if this is a device we care about and to get information about it. It
seems like you've mostly got that part figured out, but my guess is
that the single reader aspect of devd is probably a showstopper unless
you have another system-wide daemon to multiplex the events out to
clients.

--
Dan