Ctrl-Alt-Shift issue when checking for USB monitors

[gitfib]

When running sudo ddcutil usbenv --verbose without USB devices connected, there's no issue, but if the mouse is connected then it creates an issue that looks like Ctrl and Shift keys are stuck on keydown, and I can't use plasma-hud (which I have set to Alt)

I've confirmed the issue occurs in both X11 (Plasma) and Wayland (Gnome), in a new user (X11) and used SSH and VNC to rule out the keyboard

On X11(it didn't work on Wayland) it's possible to press the Ctrl and Shift keys to 'release' them, but plasma-hud seems to only work when re-login

Issue reminds me of #84 so I tried sudo i2cdetect -l but it didn't give a different number of lines whether the mouse was connected or not, and it didn't have this issue. lsusb also works ok

I use ddcutil 0.9.7 on Arch, below are the results of the command usbenv-withmouse.log usbenv-nomouse.log

[rockowitz]

Thank you for the report.

Do you observe the problem with normal ddcutil commands, e.g. "detect", or just with the "usbenvironment" command?

Does the problem go away if you use command line option "--nousb"?  Monitors that use USB instead of DDC/CI for  monitor control are rare.

Please run the command "lsusb --verbose" (with the mouse attached, of course) and send the output as an attachment.

Background:  USB devices are assigned a class and subclass. Monitors, mice, keyboards, and various other devices are assigned to the Human Interface Device (HID) class (class 3).  Keyboards and mice have dedicated subclass numbers because of their special status.  ddcutil does a preliminary check of USB devices, and does further examination of the devices do not appear to be a keyboard or mouse to see if they represent a monitor.  What I believe is happening is that ddcutil is gets the preliminary check wrong and then the full query of the device is hangs the mouse.

As an alternative to using the "--nousb" option, you can instead bypass display detection for normal commands by specifying the I2C bus number on the ddcutil command, e.g. "--bus 5".  i2cdetect is one way to find the monitor. Command "i2cdetect -l" lists the I2C busses.  The question is which one is associated with the monitor.  Command "i2cdetect N", where N is an I2C bus number will show the slave addresses active on the bus.  A DDC capable monitor will indicate that slave addresses x50 and x37 are active.  (But i2cdetect will fail with DisplayPort attached monitors.) But this is probably overkill.  The "--nousb" command line option should work for you.

Regards, Sanford

On 11/2/19 9:41 AM, gitfib wrote:

When running |sudo ddcutil usbenv --verbose| without USB devices connected, there's no issue, but if the mouse is connected then it creates an issue that looks like Ctrl and Shift keys are stuck on keydown, and I can't use plasma-hud (which I have set to Alt)

I've confirmed the issue occurs in both X11 (Plasma) and Wayland (Gnome), in a new user (X11) and used SSH and VNC for the tests to rule out the keyboard

On X11(it didn't work on Wayland) it's possible to press the Ctrl and Shift keys to 'release' them, but plasma-hud seems to only work when re-login

Issue reminds me of #84 https://github.com/rockowitz/ddcutil/issues/84 so I tried |sudo i2cdetect -l| but it didn't give a different number of lines whether the mouse was connected or not, and it didn't have this issue. |lsusb| also works ok

I use ddcutil 0.9.7 on Arch, below are the results of the command usbenv-withmouse.log https://github.com/rockowitz/ddcutil/files/3800511/usbenv-withmouse.log usbenv-nomouse.log https://github.com/rockowitz/ddcutil/files/3800512/usbenv-nomouse.log

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/98?email_source=notifications&email_token=ADMGY3UYHO3VDVHVER2ZQA3QRV7RHA5CNFSM4JIFOBYKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HWKUY7Q, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3VMEFI4PNYZUKBLUC3QRV7RHANCNFSM4JIFOBYA.

[gitfib]

Do you observe the problem with normal ddcutil commands, e.g. "detect", or just with the "usbenvironment" command? Does the problem go away if you use command line option "--nousb"? Monitors that use USB instead of DDC/CI for monitor control are rare.

Yes and yes. I've just narrowed it down to the usbenv command

What I believe is happening is that ddcutil is gets the preliminary check wrong and then the full query of the device is hangs the mouse.

It's not noticeable in the mouse, so I guess the query touched someone else's memory? Here's the lsusb.log, let me know if you need anything

[rockowitz]

Thanks for sending the log. To my surprise I'm not seeing anything peculiar about your mouse (from a low level USB point of view). It's relevant information is the same as mine. The next step is to enable the relevant trace messages. Are you building from github source? If so, I'll publish the changes in the 0.9.8 branch.

Sanford

On 11/03/2019 01:56 PM, gitfib wrote:

Do you observe the problem with normal ddcutil commands, e.g.
"detect", or just with the "usbenvironment" command? Does the
problem go away if you use command line option "--nousb"? Monitors
that use USB instead of DDC/CI for monitor control are rare.

Yes and yes. I've just narrowed it down to the usbenv command

What I believe is happening is that ddcutil is
gets the preliminary check wrong and then the full query of the device
is hangs the mouse.

It's not noticeable in the mouse, so I guess the query touched someone else's memory? Here's the lsusb.log https://github.com/rockowitz/ddcutil/files/3801976/lsusb.log, let me know if you need anything

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/98?email_source=notifications&email_token=ADMGY3Q73VHNI3GTDMA5IK3QR4NGTA5CNFSM4JIFOBYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC52CDY#issuecomment-549167375, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XTIFZKXUHLMAC7GGDQR4NGTANCNFSM4JIFOBYA.

[rockowitz]

In looking at the USB related monitor detection code to see where best to enable trace messages I think I identified the path where the "don't probe this USB device, it's a mouse" check doesn't occur. It requires a non-trivial change. So for now, since the "--nousb" option works for you, will that option suffice?. I'll let you know when the modified code is up on github so you can test it out.

Thanks so much for taking the time to send the detailed reports. They made tracking down this obscure bug possible.

Sanford

On 11/03/2019 01:56 PM, gitfib wrote:

Do you observe the problem with normal ddcutil commands, e.g.
"detect", or just with the "usbenvironment" command? Does the
problem go away if you use command line option "--nousb"? Monitors
that use USB instead of DDC/CI for monitor control are rare.

Yes and yes. I've just narrowed it down to the usbenv command

What I believe is happening is that ddcutil is
gets the preliminary check wrong and then the full query of the device
is hangs the mouse.

It's not noticeable in the mouse, so I guess the query touched someone else's memory? Here's the lsusb.log https://github.com/rockowitz/ddcutil/files/3801976/lsusb.log, let me know if you need anything

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/98?email_source=notifications&email_token=ADMGY3Q73VHNI3GTDMA5IK3QR4NGTA5CNFSM4JIFOBYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEC52CDY#issuecomment-549167375, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3XTIFZKXUHLMAC7GGDQR4NGTANCNFSM4JIFOBYA.

[gitfib]

Thank you for your kind words. I don't mind using --nousb, I just want to help fixing it. From the 0.9.8, do I just usbenv --verbose as usual?

I tried to gdb and use breakpoint after query_usb_monitors(), but running detect doesn't trigger it yet it still has the issue, so I'm not sure where to put the breakpoint. In case it helps, after the issue happens once, it won't happen again before a reboot

[rockowitz]

On 11/04/2019 02:30 PM, gitfib wrote:

Thank you for your kind words. I don't mind using --nousb, I just want to help fixing it. From the 0.9.8, do I just |usbenv --verbose| as usual?

"--nousb" does not disable the usbenvironment command (I suppose it should). So just avoid it. The environment and usbenvironment commands ignore all the well-constructed layering, in order to diagnose the user's ddcutil installation.

I've found the point in the normal code path where a mouse might be mistaken for a possible display, and have added code to address that.
The corresponding check needs to be made in usbenvironment, and the code cleaned up. Given that it's not urgent it probably be a few weeks before the changes make it into github.

For what it's worth, one vagary is that the code path is affected by whether you're running as root. If not, you probably don't have permission to open the relevant /dev/hiddev device, so the problem can't be triggered.

Sanford

I tried to gdb and use breakpoint after query_usb_monitors(), but running |detect| doesn't trigger it yet it still has the issue, so I'm not sure where to put the breakpoint. In case it helps, after the issue happens once, it won't happen again before a reboot

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/98?email_source=notifications&email_token=ADMGY3WX5E4KAFXR2EQH7NTQSBZ65A5CNFSM4JIFOBYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDAN4ZQ#issuecomment-549510758, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3UMRHUIRBWFAQ7WVOTQSBZ65ANCNFSM4JIFOBYA.

[rockowitz]

The 0.9.8 branch on GitHub contains a fix for the mouse hang problem.
The fix occurs in 3 locations: normal display detection, the "usbenvironment" command, and the "chkusbmon" command intended to be called from a UDEV rule.

If you can build from he 0.9.8 branch it would be most helpful to see if the problem is indeed resolved.

Sanford

On 11/04/2019 02:30 PM, gitfib wrote:

Thank you for your kind words. I don't mind using --nousb, I just want to help fixing it. From the 0.9.8, do I just |usbenv --verbose| as usual?

I tried to gdb and use breakpoint after query_usb_monitors(), but running |detect| doesn't trigger it yet it still has the issue, so I'm not sure where to put the breakpoint. In case it helps, after the issue happens once, it won't happen again before a reboot

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/98?email_source=notifications&email_token=ADMGY3WX5E4KAFXR2EQH7NTQSBZ65A5CNFSM4JIFOBYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEDAN4ZQ#issuecomment-549510758, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3UMRHUIRBWFAQ7WVOTQSBZ65ANCNFSM4JIFOBYA.

[gitfib]

Yes, it's fixed! Thank you

[rockowitz]

And thank you for the detailed reports. They enabled me to hone in on the problem.

Regards, Sanford

On 11/15/2019 06:04 AM, gitfib wrote:

Yes, it's fixed! Thank you

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/rockowitz/ddcutil/issues/98?email_source=notifications&email_token=ADMGY3RLU352M2AQE72EP5LQTZ63ZA5CNFSM4JIFOBYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEFDMJQ#issuecomment-554317350, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADMGY3UT7MCP2SSLLCVNKSDQTZ63ZANCNFSM4JIFOBYA.