Closed maxatome closed 1 year ago
Have you looked at the USB transactions going on, using usbdump?
I just did it for both cases. See the dumps below. Note the
############# HERE LAUNCH: /usr/local/sbin/webcamd -i 0 -d ugen0.5 -U webcamd -G webcamd
line, just before webcamd
launching.
```raw
> usbdump -i usbus0 -f 5 -s65536 -vvv
20:42:15.841765 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
0000 80 06 00 01 00 00 08 00 -- -- -- -- -- -- -- -- |........ |
frame[1] READ 8 bytes
flags 0 <0>
status 0xca1a3
```raw
> usbdump -i usbus0 -f 5 -s65536 -vvv
20:50:27.096671 usbus0.5 SUBM-CTRL-EP=00000080,SPD=FULL,NFR=2,SLEN=8,IVAL=0
frame[0] WRITE 8 bytes
0000 80 06 00 01 00 00 08 00 -- -- -- -- -- -- -- -- |........ |
frame[1] READ 8 bytes
flags 0 <0>
status 0xca1a3
I see an "ERR=IOERROR" in the failure case.
Could you compile webcamd with debug support? You simply do "make config" in the ports and enable DEBUG.
Then "make clean" and "make reinstall".
Likely the device returns a failure on that INTERRUPT endpoint, which should be a valid packet instead.
Then you need to run webcamd in the foreground and watch for any error printouts. There may also be some module debug parameters you need to set. See man webcamd for more information.
--HPS
Failure and OK cases produce the same output:
> webcamd -i 0 -d ugen0.5 -U webcamd -G webcamd
webcamd 18750 - - IR NEC protocol handler initialized
webcamd 18750 - - IR RC5(x/sz) protocol handler initialized
webcamd 18750 - - IR RC6 protocol handler initialized
webcamd 18750 - - IR JVC protocol handler initialized
webcamd 18750 - - IR Sony protocol handler initialized
webcamd 18750 - - IR SANYO protocol handler initialized
webcamd 18750 - - IR XMP protocol handler initialized
webcamd 18750 - - b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully
webcamd 18750 - - cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
webcamd 18750 - - v4l2loopback driver version 0.12.5 loaded
webcamd 18750 - - Attached to ugen0.5[0]
webcamd 18750 - - DBG: input0: joydev: blacklisting 'Wacom Intuos S Pen'
webcamd 18750 - - DBG: 0003:056A:0374.0001: input_register_device: registering input0 with devres.
TODO: Implement devres_destroy()
webcamd 18750 - - DBG: 0003:056A:0374.0001: input_register_device: registering input2 with devres.
webcamd 18750 - - INFO: 0003:056A:0374.0001: : USB HID v1.10 Device [Wacom Co.,Ltd. Intuos S] on usb-/dev/usb-/dev/usb/input0
webcamd 18750 - - Creating /dev/input/event9
webcamd 18750 - - Creating /dev/input/event10
webcamd 18750 - - Creating /dev/input/js0
(except the failure case quits immediately as said previously.)
I didn't find any debug parameters to set... Perhaps am I missing something :(
Can you try the following command, and see if you find anything relevant?
webcamd -s | grep debug
As it seems media_tree/drivers/hid/wacom_wac.c
is involved, webcamd -s
only lists wacom_wac.touch_arbitration
param which can match but is not related to any debugging facility.
In addition, just to be sure, setting all webcamd -s
listed *debug
parameters to 1, do not change anything to the output.
If you are familiar with GDB (should be installed from ports/pkg), then you can set a breakpoint on the probe function in there and step through it all. It should be something in there which triggers the bug, and maybe you learn something? OK?
--HPS
So, after some digging, webcamd
exits here: https://github.com/hselasky/webcamd/blob/75ec0e3c4171664a0c3798e7331c217828d84b6b/kernel/linux_usb.c#L191
ioctl
fails with Device not configured
error.
err
returned by libusb20_dev_process()
call, a few lines above is -99.
If webcamd returns at line 191, it means the device has detached! Could you check dmesg what is going on?
it means the device has detached!
Yes, that is what devd events show in my initial message. But this "detachment" seems to be a consequence of webcamd behavior (perhaps when it encounters the ERR=IOERROR you noticed? or another case), as if we delay the launch of webcamd it works flawlessly...
I'll copy/paste messages logs tonight.
The ERR=IOERROR is bundled with the completion of a USB transaction. Would you be able to capture that and backtrace and dump the so-called urb structure? Also dumping all threads and their backtraces at this point would be useful. That would shed some more light into what is going on around this ERR=IOERROR. Maybe some USB transaction is simply missing a timeout and needs a re-try.
messages logs:
Feb 1 20:40:45 yocto kernel: ugen0.5: <Wacom Co.,Ltd. Intuos S> at usbus0
Feb 1 20:40:45 yocto kernel: uhid2 on uhub0
Feb 1 20:40:45 yocto kernel: uhid2: <Wacom Co.,Ltd. Intuos S, class 0/0, rev 2.00/1.11, addr 6> on usbus0
launch of webcamd
then:
Feb 1 20:40:47 yocto kernel: uhid2: at uhub0, port 6, addr 6 (disconnected)
Feb 1 20:40:47 yocto kernel: uhid2: detached
Feb 1 20:40:48 yocto kernel: ugen0.5: <Wacom Co.,Ltd. Intuos S> at usbus0 (disconnected)
Feb 1 20:40:48 yocto kernel: ugen0.5: <Wacom Co.,Ltd. Intuos S> at usbus0
Feb 1 20:40:48 yocto kernel: uhid2 on uhub0
Feb 1 20:40:48 yocto kernel: uhid2: <Wacom Co.,Ltd. Intuos S, class 0/0, rev 2.00/1.11, addr 7> on usbus0
and when it succeeds:
Feb 1 23:19:49 yocto kernel: ugen0.5: <Wacom Co.,Ltd. Intuos S> at usbus0
Feb 1 23:19:49 yocto kernel: uhid2 on uhub0
Feb 1 23:19:49 yocto kernel: uhid2: <Wacom Co.,Ltd. Intuos S, class 0/0, rev 2.00/1.11, addr 19> on usbus0
launch of webcamd then:
Feb 1 23:20:17 yocto kernel: uhid2: at uhub0, port 6, addr 19 (disconnected)
Feb 1 23:20:17 yocto kernel: uhid2: detached
I tried to add UQ_HID_IGNORE
quirk: the same problem persists, we just get rid of all uhid2
messages.
I didn't find the place where the error is emitted and/or what raises the detachment.
The following re-attach comes from the tablet with a different vendor ID 0x2d1f (but still Wacom behind the scene), like a defensive measure for a new try on host side with this new ID.
Are you able to figure out the last URB's submitted and USB control endpoint commands happening right before the "(disconnected)" message. I suspect we are triggering something inside the device. Maybe we need to relax the timing of some USB commands simply. I.E. FreeBSD is very fast even faster than Linux in this regard, because we don't allocate any memory in the fast-path, so to speak.
Ping?
I am sorry I haven't had time to dig further. The last time I tried, I didn't succeed to get these last actions before the disconnection. I said to myself that I will try again later when I have more time which did not happen...
Hi,
After disabling the
match "vendor" "0x056a";
corresponding block in/usr/local/etc/devd/webcamd.conf
.Plugging the pen tablet produces the following devd events:
then launching:
always displays:
when it works, it produces the following devd events:
but often, it quits almost immediately producing the following devd events:
After several tests, it seems that if I wait at least 10 seconds before launching webcamd, it works all the times.
So modifying the devd action as:
does the trick…
Not sure it is the only way to fix this problem, so just in case I open this issue :)
Thanks!