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

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Thu Mar 16 11:42:33 UTC 2017


--- Comment #72 from Matthew Rezny <rezny at freebsd.org> ---
(In reply to Jan Beich (mail not working) from comment #71)

I have not tried the HAL code in years since it did not work for me, but I saw
similar with the udev config code active, so I do not believe it specific to
the devd backend. With the isParent check in place, X doesn't let go of the
input device and thus devd doesn't send the removal notice until I do a VT
switch, which interrupts all the inputs. I also noticed that reconnecting the
tablet creates a /dev/event/inputX+1 to which another instance of the wacom
driver attaches. All the instances stay connected, spamming the log, until VT

The way I understood that comment in UnInit is that newer X server will call
UnInit for every child device in correct order whereas old server did not. The
old UnInit code checks to see if the device it was handed isParent, and if so
it runs through and removes all devices for which isParent is false, i.e. the
children. Given that, the check for isParent appears to be in the wrong place.
Instead of checking priv->isParent initially, which would only be true if the
I/O error occurs while the parent device is attempting a read, check
!other->isParent in the for loop.

Unfortunately, this is more complex that it appears at first glance.
DeleteInputDeviceRequest is not safe to call here. It looked like it was ok the
first time, but most of the time I get multiple backtraces in the log upon

[523237.117] (EE) BUG: triggered 'if (in_input_thread())'
[523237.117] (EE) BUG: io.c:656 in WriteToClient()
[523237.118] (EE) ******** WriteToClient called from input thread *********
[523237.118] (EE) 
[523237.118] (EE) Backtrace:
[523237.142] (EE) 0: /usr/local/bin/Xorg (WriteToClient+0x78) [0x5aa0d8]
[523237.162] (EE) 1: /usr/local/bin/Xorg (WriteEventsToClient+0x187) [0x441657]
[523237.184] (EE) 2: /usr/local/bin/Xorg (TryClientEvents+0x1dc) [0x4414bc]
[523237.204] (EE) 3: /usr/local/bin/Xorg (DeliverRawEvent+0x834) [0x442b34]
[523237.225] (EE) 4: /usr/local/bin/Xorg (DeliverEventsToWindow+0x35c)
[523237.245] (EE) 5: /usr/local/bin/Xorg (XIGetDevice+0xd58) [0x529bd8]
[523237.266] (EE) 6: /usr/local/bin/Xorg (DisableDevice+0x2d8) [0x42ca08]
[523237.286] (EE) 7: /usr/local/bin/Xorg (RemoveDevice+0xcd) [0x42db9d]
[523237.307] (EE) 8: /usr/local/bin/Xorg (DeleteInputDeviceRequest+0x38)
[523237.327] (EE) 9: /usr/local/lib/xorg/modules/input/wacom_drv.so
(_init+0x17f5) [0x811f3a925]
[523237.348] (EE) 10: /usr/local/lib/xorg/modules/input/wacom_drv.so
(_init+0x841) [0x811f38a71]
[523237.369] (EE) 11: /usr/local/bin/Xorg (xthread_sigmask+0xee) [0x5a936e]
[523237.389] (EE) 12: /usr/local/bin/Xorg (OsCleanup+0x4cf) [0x5ab51f]
[523237.409] (EE) 13: /usr/local/bin/Xorg (input_force_unlock+0x712) [0x5a9572]
[523237.430] (EE) 14: /lib/libthr.so.3 (_pthread_create+0x915) [0x80256e365]
[523237.450] (EE) 15: ? (?+0x915) [0x915]

It turns out that patching the wacom DDX is not all that practical. The way
input is handled was changed in 1.19, now there is an input thread on which the
I/O occurs and we can't go removing or disabling device from within the thread,
rather we would need to signal across threads. The better way to solve this is
at the root of the problem; instead of patching every input driver just fix
webcamd so it removes device nodes for disconnected devices.

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

More information about the freebsd-x11 mailing list