[Bug 196678] x11-servers/xorg-server: make config/devd recognize /dev/input/eventX from multimedia/webcamd

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678

--- Comment #61 from Matthew Rezny <rezny at freebsd.org> ---
These are the results of my testing for reference. The situation is improved
although not yet perfect. 

Input devices are a PS/2 keyboard, a USB2.0 laser-mouse, and a USB1.1 Wacom
Graphire3. Kbdmux and sysmouse are in use so the keyboard and mouse situation
is easy, those has worked worked with the devd backend since the beginning. The
Wacom tablet is the tricky part since up till now it required static config in
xorg.conf.d (using half the example file in the port), so it must be present
when X starts, but it must NOT be present when the machine boots since ums
would take the device before the wacom script in rc.d has a chance to setup the
usb_quirks to prevent ums stealing the device. When using a graphical login
manager, the result is a window of a few seconds in which the tablet can be
plugged in and expected to work correctly; far from ideal. For a while it was
possible to avoid the hassle by putting the usb_quirk data in loader.conf, but
that no longer works, so it is important to be able to hot-plug the tablet
after X is already started.

Using the old devd code patched for 1.19 compat was the the same situation, no
handling the wacom table when it is connected.

Using the last patch posted in this PR, modified for 1.19 compat, resulted in
the wacom tablet being detected but the evdev driver was loaded, even if I also
had a file in xorg.conf.d explicitly specifying the wacom driver. Only if I
uninstalled xf86-input-evdev would the wacom driver get loaded. The evdev DDX
is not suitable for use with my wacom tablet. When that driver loads, the
cursor becomes stuck to the left edge of the screen, button 1 is stuck in the
down state, moving the stylus horizontally causes the cursor to move
vertically, and I cannot move the cursor elsewhere or click with the mouse
since evdev is feeding (incorrect) absolute coordinates from the tablet and a
button is already stuck.

After I reworked the devd code and killed at least one obvious bug handling the
entries in the device type table, but also passing path as well as device for
evdev's benefit, the situation is improved; with both evdev and wacom drivers
installed, devd loads the the wacom driver when the tablet is connected and it
works as expected. Hooray, getting closer... except there is an issue when
unplugging the tablet, a case I had never tired with the old code knowing
there'd be no way to reconnect without restarting X. When the tablet is
unplugged, the log is flooded with errors from the wacom driver which is
freaking out because it can't read from the device.

For comparison I gave the udev config backend a shot. The first run looked good
for the tablet, wacom driver loads and tablet works, I can disconnect and
reconnect the tablet and it still works without flooding the log, but I have no
keyboard or mouse. The log showed that the keyboard and mouse devices were
offered to the server but no driver was loaded. After skimming the udev code,
I'm not sure how it should work, unless perhaps it only works with devices that
supply evdev events, because "driver" is never added of the the options list
used to add the device. So, I patched the udev config code to include "driver"
with value of "kbd" or "mouse" when the device is one of those types. The
result is the udev backend now behaves the same as the devd backend, keyboard
and mouse drivers are loaded for kbdmux and sysmouse, and the wacom driver
loads for the tablet, but when I disconnect the tablet the log is flooded and
upon reconnecting it does not work because the old instance was never unloaded.
Hmmm....

In order to troubleshoot I added extra logging in device_removed() so we can
see what is happening when the tablet is disconnected. When the tablet is
connected, /dev/ugenX.Y and /dev/hid2 appear, neither of which attach drivers
(the former is ignored by device_added, the latter has no driver match), hid2
detaches, webcamd starts for the ugenX.Y device and creates a
/dev/input/event0, devd sends another event, and finally device_added() loads
the wacom driver which attaches to the device. When the tablet is connected,
the only thing in the log before the continuous error blast starts is
device_removed() ignoring the disconnect of /dev/ugenX.Y; there was no removal
event received for /dev/input/event0 and that device node still exists in the
filesystem.

My first guess is the device for the hardware is immediately removed but
webcamd doesn't remove the synthetic device while it is still opened. However,
that doesn't explain the situation with the udev backend. When there was no
driver loaded for the keyboard or mouse, it saw the removal of
/dev/input/event0 and correctly detached and unloaded the wacom driver, but
once I had fixed it to load those keyboard and mouse drivers it no longer saw a
removal of the tablet.

Also, there are a number of /dev/hidX entries for various USB device for which
no driver is loaded when device_added() processes them. nothing ever loads for
/dev/hidX entries regardless of the type. /dev/hid0 is the keypad on a USB
handset which should be numeric input and volume up/down, /dev/hid1 is the
laser mouse (in parallel with /dev/ums0), and /dev/hid2 is the wacom tablet
without webcamd loaded, which now does nothing although once upon a time the
wacom DDX did work without webcamd (unsure when that changed). Finally, I tried
connecting a USB gamepad I had almost forgotten about since it has never worked
in X with the joystick driver, but of course it shows up as a /dev/hidX and no
driver attaches. While I have older joysticks that connect to the game port and
which have worked (long ago, not tested in years) with the joystick driver and
an entry in xorg.conf, those have not been tested with the new devd config
code.

Summary: The situation is improved as I can now plug in the tablet any time
after boot including after starting X, but still I cannot disconnect the tablet
without having to restart X to reconnect it.

HPS: Since webcamd is yours, do you have anything to suggest regarding the
missing removal of /dev/input/event0 when disconnecting the wacom tablet while
the wacom driver is attached?

-- 
You are receiving this mail because:
You are the assignee for the bug.