Date: Fri, 10 Mar 2017 17:51:28 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-x11@FreeBSD.org Subject: [Bug 196678] x11-servers/xorg-server: make config/devd recognize /dev/input/eventX from multimedia/webcamd Message-ID: <bug-196678-8047-UpT3FEqdcK@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-196678-8047@https.bugs.freebsd.org/bugzilla/> References: <bug-196678-8047@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D196678 --- Comment #61 from Matthew Rezny <rezny@freebsd.org> --- These are the results of my testing for reference. The situation is improved although not yet perfect.=20 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 situati= on 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 w= as 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 D= DX 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 t= he 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 f= or evdev's benefit, the situation is improved; with both evdev and wacom drive= rs 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 hav= e 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 cod= e, 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 "driv= er" 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, keyboa= rd 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 a= nd upon reconnecting it does not work because the old instance was never unloa= ded. 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 drive= rs (the former is ignored by device_added, the latter has no driver match), hi= d2 detaches, webcamd starts for the ugenX.Y device and creates a /dev/input/event0, devd sends another event, and finally device_added() loa= ds 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 remo= val event received for /dev/input/event0 and that device node still exists in t= he 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. Howev= er, 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 s= aw a removal of the tablet. Also, there are a number of /dev/hidX entries for various USB device for wh= ich 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 t= ried connecting a USB gamepad I had almost forgotten about since it has never wo= rked 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 ta= blet 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 wh= ile the wacom driver is attached? --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-196678-8047-UpT3FEqdcK>