Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 16 Mar 2017 11:42:33 +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-FpCVS0y9y6@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 #72 from Matthew Rezny <rezny@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 t=
he
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
switch.

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. t=
he
children. Given that, the check for isParent appears to be in the wrong pla=
ce.
Instead of checking priv->isParent initially, which would only be true if t=
he
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
disconnect.

[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)=20
[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) [0x441=
657]
[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)
[0x441a5c]
[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)
[0x489238]
[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) [0x5a9=
572]
[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 thr=
ead,
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.

--=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-FpCVS0y9y6>