Opened 6 years ago

Closed 2 years ago

#14523 closed bug (fixed)

USB wireless keyboard/mouse not working after unplug (throug KVM)

Reported by: roiredxsoto Owned by: nobody
Priority: normal Milestone: R1/beta4
Component: Drivers/Input/HID/USB Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All

Description

Good day,

Setup: Microsoft Wireles Comfort Desktop 5050 plugged to Ugreen KVM USB switch, connected to 2 PC's, one Haiku, one work PC. On Haiku is connected to USB 2.0 port on the motherboard.

Switching from one Haiku to the other PC causes Haiku not recognize mouse/keyboard when switching back to Haiku.

Thank you for your assistance, Regards, RR

Attachments (6)

20180925-Listusb14523 (4.6 KB ) - added by roiredxsoto 6 years ago.
uname+listdev+listusb of the box
20180925-syslog-afterusb (233.5 KB ) - added by roiredxsoto 6 years ago.
syslog after restarting once the usb lock happened
20180925-previous_syslogWhenlock (217.1 KB ) - added by roiredxsoto 6 years ago.
Previous syslog, I understand is the one when the "Lock" happened
IMG_20200902_130017270.jpg (1.1 MB ) - added by roiredxsoto 4 years ago.
Trip to KDL when switching to Haiku from the Keyboard-Mouse switch
screenshot2.png (75.5 KB ) - added by roiredxsoto 4 years ago.
Input preferences showing the increasing list of Input devices
syslog (414.9 KB ) - added by roiredxsoto 4 years ago.
Syslog from session switching back and forth from Windows Box to Haiku box

Change History (21)

by roiredxsoto, 6 years ago

Attachment: 20180925-Listusb14523 added

uname+listdev+listusb of the box

by roiredxsoto, 6 years ago

Attachment: 20180925-syslog-afterusb added

syslog after restarting once the usb lock happened

by roiredxsoto, 6 years ago

Previous syslog, I understand is the one when the "Lock" happened

comment:1 by roiredxsoto, 6 years ago

Good day,

Forgot to report that, once unplugged, can't use front USB ports either (those are USB 3.0, but set to legacy support inside BIOS).

Attached files with syslog and dev/usb.

Regards, RR

comment:2 by diver, 6 years ago

Component: - GeneralDrivers/Keyboard/PS2
ps2: keyboard reset failed, status 0x80000001, data 0xff
ps2: keyboard probing failed

comment:3 by diver, 6 years ago

Probably a dupe of #7958.

comment:4 by roiredxsoto, 6 years ago

Good day,

Actually, this happens on the Ryzen box, but does not happen on the laptop (Intel Core2Duo), which only has USB 2.0, and where I can plug, unplug mouse, wacom, and have no issues recognizing any device. Both systems are running the same hrev, hrev52379 64bits, so it is a bit weird.

Thanks. Regards, RR

comment:5 by vidrep, 6 years ago

Does it sound anything like this ticket? #11793

in reply to:  5 comment:6 by roiredxsoto, 6 years ago

Replying to vidrep:

Does it sound anything like this ticket? #11793

Good day vidrep, Yep... I presume, after reading that ticket that might be the same issue. So as that ticket is older, I think better option is to move the info provided in this one to that. In fact, I was going to add a KDL screen capture here now, and later the syslog, but after reading your post I will do to that one (#11793). Though I presume there must be something more involved. If can merge both tickets into one, with all the info I provided here might be easier to analise. Thanks for your indication. Regards, RR

comment:7 by waddlesplash, 6 years ago

Component: Drivers/Keyboard/PS2Drivers/Input/PS2/Keyboard

comment:8 by roiredxsoto, 4 years ago

Good day,

Yesterday and today, its working without issues using the USB 2.0 port on the Haiku (BM) box. It is certain that the USB port is the 2.0. Right now I'm not sure, as I can't recall it correctly, but it seems that I had made a mistake when reporting the issue at the beginning. This time I am absolutely certain that I'm using an USB 2.0 port to plug the switch to.

Sincere apologies for wasting your time. I'll try to be 100% sure next time I report some issue. Regards, RR

I've been using the keyboard and mouse for some time already and they both seem to work fine. Just need to be aware to switch from time to time. If I switch to the winbox and take long time to go back to the Haikbox, then Haiku does not get the change properly. Looks like the "usb watcher" went to sleep and does not wake up. Other than that, I've been switching machines often. It's not fully 100% solved yet, but a great improvement from before. Thank you very much. Regards, RR

Last edited 4 years ago by roiredxsoto (previous) (diff)

by roiredxsoto, 4 years ago

Attachment: IMG_20200902_130017270.jpg added

Trip to KDL when switching to Haiku from the Keyboard-Mouse switch

comment:9 by roiredxsoto, 4 years ago

Good day,

As this ticket seems to be the same as the #11793 and I've been reporting to that ticket, I think this can be marked as solved or delete it and keep only that one active. I'll be performing more testing regarding that, and will add any issue that might appear.

Thanks,
Regards,
RR

comment:10 by roiredxsoto, 4 years ago

Good day,

As pointed out by @Pulkomandy, this ticket is different from #11793, therefore I will keep updating info here:

~> listusb
1ea7:0907 /dev/bus/usb/0/10/2 "SHARKOON Technologies GmbH" "USB-HID Gaming Keyboard" ver. 0300
045e:0773 /dev/bus/usb/0/10/3 "Microsoft Corp." "Microsoft Nano Transceiver v1.0" ver. 0674
05e3:0610 /dev/bus/usb/0/10/hub "Genesys Logic, Inc." "4-port hub" ver. 9226
0000:0000 /dev/bus/usb/0/hub "HAIKU Inc." "XHCI RootHub" ver. 0300
0000:0000 /dev/bus/usb/1/hub "HAIKU Inc." "XHCI RootHub" ver. 0300
0000:0000 /dev/bus/usb/2/hub "HAIKU Inc." "XHCI RootHub" ver. 0300
~> uname -a
nHaiku hawku 1 hrev55039 Apr 15 2021 06:02:38 x86_64 x86_64 Haiku

With latest Haiku revision, the issue is still there, though it appears to experience some improvements. I can switch from Windows to Haiku and viceversa if the time between switching is short. If I wait too much between switching to Haiku, Haiku ends up not responding at all needing a forced shutdown and reboot.

What I've been seeing is that when the switch works, everytime I switch from Windows to Haiku Input preferences registers the same devices again and again filling the Input Preferences listbox with repeated devices while 'listusb' command keeps reporting the same.

Attached is a pic of the Input preferences (same as posted in the forums). Also the Syslog.

Regards,
RR

by roiredxsoto, 4 years ago

Attachment: screenshot2.png added

Input preferences showing the increasing list of Input devices

by roiredxsoto, 4 years ago

Attachment: syslog added

Syslog from session switching back and forth from Windows Box to Haiku box

comment:11 by waddlesplash, 3 years ago

Please retest on a recent nightly.

comment:12 by roiredxsoto, 3 years ago

Good day,

@waddlesplash, I retested with recent nightly and with beta 3 up to date and in both situations still the issue is present, though not as critical as before. Right now I can switch back and forth between windows and haiku several times before the lock occurs. Even sometimes it looks like the lock is going to take place and then mouse and keyboard start to respond.

I can't elaborate a pattern on when it happens, because it seems random. Please let me know what info I can provide to get a better understanding on this issue.

Regards,
RR

comment:13 by waddlesplash, 3 years ago

Component: Drivers/Input/PS2/KeyboardDrivers/Input/USB-HID

Please retest under a recent nightly, and if the problem still happens, upload a syslog. The changes to XHCI transfer cancellation may have affected this.

comment:14 by roiredxsoto, 2 years ago

Good day @waddlesplash,

I've been testing this weekend if any issues were present. First updating to latest nightly, and then performing the tests.

I did perform several tests:

  • Quick change from one device to the other and back
  • Slow change from one device to the other and back (several minutes interval)
  • Super Slow. Wait until Haiku screen goes down and back.

In all these tests I didn't experience any issues nor locks. Keyboard and trackball responded fine in each situation after switching back to Haiku, regardless the wait time before coming back.

In my case, I would set this as 'solved/closed', though if you allow me, I will keep an eye, and keep testing, just in case I need to reopen this bug.

Thanks a lot! Regards
RR

comment:15 by waddlesplash, 2 years ago

Milestone: UnscheduledR1/beta4
Resolution: fixed
Status: newclosed

Very good, thanks for testing!

Note: See TracTickets for help on using tickets.