populating /dev from /sys

[Karl Godt]

Yesterday I run into real trouble :

Xorg.0.log :

[ 3298.493] (**) ModulePath set to "/usr/lib64/xorg/modules"
[ 3298.498] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled.
[ 3298.500] (WW) Disabling Mouse0
[ 3298.502] (WW) Disabling Keyboard0

When no udev is running, Xorg s from binary builds may go to desktop but without input enabled .
No keys working to switch to terminal or quitting the Xorg server .

Am not sure what causes it , but I suspect udev dependencies :

Code: Select all

commit a6273cc85c01fc020643a68e49ca4e7a2d2ae898
Author: Peter Hutterer <peter.hutterer@who-t.net>
Date:   Thu Jan 12 10:17:34 2012 +1000

    xfree86: mention udev in the xorg.conf manpage AutoAddDevices section
    
    And point out what "hotplugging" means.
    
    Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net>
    Reviewed-by: Julien Cristau <jcristau@debian.org>

[technosaurus]

yes its on my to-do list to look into patching X to run properly without libudev (need to find the commit that added it), but in the mean time tinyxserver is a self sufficient replacement.
I think a standard device fallback for each input would be sufficient if another utility maps actual input devices to those standard ones (via symlinks or whatever).

[jamesbond]

When no udev is running, Xorg s from binary builds may go to desktop but without input enabled .
No keys working to switch to terminal or quitting the Xorg server .

Code: Select all

Section "ServerFlags"
  Option "AutoAddDevices" "false"
  Option "DontZap" "false"
EndSection

Add this snippet to your xorg.conf, it should help. It forces Xorg to disable hotplugging and uses configuration sections on your xorg.conf.

@technosaurus - I'm interested if you can find how to remove udev dependency from Xorg but still be able to have hotplugging (using other means).

[technosaurus]

it previously used hal so I can look at that. I was thinking since they split the config files, an inotify-watch on that directory for added/changed events would be logical (kqueue for bsd) Then the hotplug handler only has to add/modify a file. This can be done in shell, c, or whatever.

It talks about getting input setup in the 1.8 and 1.9 release notes without udev btw

[Ibidem]

FYI, I've written an experimental library intended to use as a fallback/replacement for some of the features libudev offers.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.

There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.

[technosaurus]

FYI, I've written an experimental library intended to use as a fallback/replacement for some of the features libudev offers.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.

There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.

I may be wrong, but I think those events are handled internally -- it needs help with hot plug events such as plugging in a wireless mouse after X is running.

[Ibidem]

FYI, I've written an experimental library intended to use as a fallback/replacement for some of the features libudev offers.
Right now it only will map a device to a sysfs directory and get the PCI IDs if they're available.
Source is over at https://github.com/idunham/libsysdev; the first port of anything to use it is https://github.com/idunham/xf86-input-evdev, branch sysdev
The API is intended to make porting Mesa to it simple.

There's no "listen for events" code, though. I might see about something to make it easy to listen to inotify events in /dev/input and /dev/block or /dev/disk.

I may be wrong, but I think those events are handled internally -- it needs help with hot plug events such as plugging in a wireless mouse after X is running.

Might I ask what "those events" refers to in your comment?

The inotify bit is one possible way of listening for hotplug events.
Hotplugging a GPU/input device means a new device appears in /dev/dri or /dev/input, or an old one disappears; I'm figuring that we can check for that by means of an inotify watch.

As far as I can tell after skimming xorg-xserver source, there are several possible "config" backends for the X server that seem to be responsible for hotplugging; the main code for these is in config/<backend>.c, and I can't really tell exactly where they hook up or how X listens for hotplug events.
I do know config/config.c calls the setup and teardown needed for "the current config backend", and include/hotplug.h declares the functions in config/config.c.
You can build the server with any one of several config backends, or with none; wscons, udev, and HAL are the currently available backends.
Each of these will try to figure out an appropriate driver for each device, then load that driver specifying the device.
When evdev is the driver loaded, it will check whether an input device is "virtual" or not (meaning roughly "is it a pointer or keyboard, or is it something else?") so it knows whether to refuse to proceed.
The way evdev checks this is by finding the corresponding sysfs path and checking if it contains the string "LNXSYSTEM"--if evdev finds that string, it bails out.
Generating this path is currently done by libudev.

mesa somehow-or-other ends up with an fd for a DRI device (without using udev), then uses udev (or some sysfs fallback code that you must manually enable) to get the corresponding PCI ids and parses those PCI ids to determine the mesa driver.

...Ah, that's it: the udev backend installs a wakeup handler (named wakeup_handler(), of course) with RegisterBlockAndWakeupHandlers(). But I'm not sure exactly how all that works; it's a bit above my pay grade . Perhaps udev sends a signal, perhaps it's something along the lines of select() on a socket...

[technosaurus]

I was referring to button/key presses

A netlink socket like udev uses will catch hotplug events ... example here:
https://www.kernel.org/doc/pending/hotplug.txt

[Ibidem]

I was referring to button/key presses

A netlink socket like udev uses will catch hotplug events ... example here:
https://www.kernel.org/doc/pending/hotplug.txt

I'm more wondering how to make X11 catch hotplugging (esp. devices appearing)...without depending on a particular hotplug helper.
In particular, my hope is to work with mdev, vdev, udev, hotplug2, or even static /dev.
If someone runs mknod /dev/input/mouse1 c 4 64 from an xterm, it would be nice if X could go "Ah, there's a new...mouse! Let's load *that* driver!"

[technosaurus]

I know it may sound ridiculous but, the X server could be used as the hotplug handler by just monitoring the netlink hotplug socket in the same loop as the unix domain (or tcp) socket ... or even use select(). For _most_ users the X server is, for all intents and purposes, essentially a daemon anyhow. In fact as part of my nanosaurus experiment, Xvesa and jwm were forked off of /init as if they were a daemon.

[amigo]

Currently, the only two places to catch kernel events are from using netlink, like udev does, or from using /sbin/hotplug, The hotplug interface is more limited as it only responds to 'add' or 'remove' events. The systemd guys want to replace netlink with a d-bus implementation in the kernel -kdbus. If you don't want to depend on anything, then you need to re-implement any of the above functionalities -but why re-do what is already there. Especially if it means having to patch and maintain patches to any program wishing to use those services. netlink is already in the kernel, so why not just use it and be happy?

[technosaurus]

-but why re-do what is already there. Especially if it means having to patch and maintain patches to any program wishing to use those services. netlink is already in the kernel, so why not just use it and be happy?

netlink requires a continuously running daemon ... I for one don't continuously add/remove devices enough to warrant an extra running process. The problem with the old hotplug scripts is that they mandated posix sh compliance and thus made a bunch of calls to external binaries. Builtin read and substring manipulation can replace most external calls to the extent that the user won't even see a time lapse. With a couple of minor modifications to busybox (marking more things like mknod as nofork/noexec) you get near udev performance without the overhead of a udevd.

[amigo]

Hmmm, I'm probably the last person on the planet who stopped using hotplug! -back in the day when udev was debated just like systemd is these days. In between, we had the same for hald and the *-Kit's...

I'm all for a better /sbin/hotplug, although making it depend on busybox doesn't sound nice either. I worked on some stuff for hotplug using bash3. There are the two other disadvantages of hotplug -seriality and the fact that it passes less environment to the handler(which might provide extra options/functionality).

[technosaurus]

I'm all for a better /sbin/hotplug, although making it depend on busybox doesn't sound nice either. I worked on some stuff for hotplug using bash3. There are the two other disadvantages of hotplug -seriality and the fact that it passes less environment to the handler(which might provide extra options/functionality).

I'm not saying that we should, just that busybox could perform at speeds close to that of udevd ... any modern shell will work, but having things like mknod (and other required external binaries) as a builtin would improve performance.