USB issues with mouse and keyboard

FreeBSD 14.3 here.

The saga begins with a K70 Corsair keyboard and a Logitech mouse, a fresh FreeBSD 14.3 install and xorg-server-21.1.18_1,1 with xfce4 as my desktop (not that the latter is relevant). My keyboard and mouse are on an Anker hub.

If I boot with hw.usb.usbhid.enable=0:

kernel: [719116] ugen3.10: <Anker Anker USB-C Hub> at usbus3 (disconnected)
...
kernel: [719136] ugen3.7: <Logitech G403 Prodigy Gaming Mouse> at usbus3
kernel: [719136] ums0 on uhub7
kernel: [719136] ums0: <Logitech G403 Prodigy Gaming Mouse, class 0/0, rev 2.00/8.03, addr 6> on usbus3
kernel: [719136] ums0: 16 buttons and [XYZT] coordinates ID=0
kernel: [719136] ukbd0 on uhub7
kernel: [719136] ukbd0: <Logitech G403 Prodigy Gaming Mouse, class 0/0, rev 2.00/8.03, addr 6> on usbus3
kernel: [719136] kbd1 at ukbd0
kernel: [719137] ugen3.8: <Corsair CORSAIR K60 RGB PRO SE Mechanical Gaming Keyboard> at usbus3
kernel: [719137] ukbd1 on uhub6
kernel: [719137] ukbd1: <Corsair CORSAIR K60 RGB PRO SE Mechanical Gaming Keyboard, class 0/0, rev 2.00/4.15, addr 7> on usbus3
kernel: [719137] kbd2 at ukbd1
kernel: [719137] uhid1 on uhub6
kernel: [719137] uhid1: <Corsair CORSAIR K60 RGB PRO SE Mechanical Gaming Keyboard, class 0/0, rev 2.00/4.15, addr 7> on usbus3
kernel: [719137] uhid2 on uhub6
kernel: [719137] uhid2: <Corsair CORSAIR K60 RGB PRO SE Mechanical Gaming Keyboard, class 0/0, rev 2.00/4.15, addr 7> on usbus3
kernel: [719137] ums1 on uhub6
kernel: [719137] ums1: <Corsair CORSAIR K60 RGB PRO SE Mechanical Gaming Keyboard, class 0/0, rev 2.00/4.15, addr 7> on usbus3
kernel: [719137] ums1: 31 buttons and [XYZ] coordinates ID=5
kernel: [719137] ugen3.9: <Anker Anker USB-C Hub> at usbus3

Now the system does two undesirable things:

1) The shift key on the K70 does nothing.
2) A moused runs for the keyboard.

Investigating this, (and from the above dmesg output) it seems ums(4) is attached to the keyboard. This is unexpected and prevents logging in if youhave any uppercase characters in your password. So I can't even see if Xorg works in this state.

If I boot with hw.usb.usbhid.enable=1 (in sysctl.conf)

kernel: [45] usbhid1 on uhub7
kernel: [45] usbhid1: <Logitech G403 Prodigy Gaming Mouse, class 0/0, rev 2.00/8.03, addr 5> on usbus3
kernel: [45] hidbus1: <HID bus> on usbhid1
kernel: [45] usbhid2 on uhub6
kernel: [45] usbhid2: <Corsair CORSAIR K70 MAX RGB Magnetic-Mechanical Gaming Keyboard, class 0/0, rev 2.00/1.11, addr 6> on usbus3
kernel: [45] hidbus2: <HID bus> on usbhid2
kernel: [45] usbhid3 on uhub6
kernel: [45] usbhid3: <Corsair CORSAIR K70 MAX RGB Magnetic-Mechanical Gaming Keyboard, class 0/0, rev 2.00/1.11, addr 6> on usbus3
kernel: [45] hidbus3: <HID bus> on usbhid3
kernel: [45] usbhid4 on uhub6
kernel: [45] usbhid4: <Corsair CORSAIR K70 MAX RGB Magnetic-Mechanical Gaming Keyboard, class 0/0, rev 2.00/1.11, addr 6> on usbus3
kernel: [45] hidbus4: <HID bus> on usbhid4
kernel: [45] hms0: <Logitech G403 Prodigy Gaming Mouse> on hidbus1
kernel: [45] hms0: 16 buttons and [XYWH] coordinates ID=0
kernel: [45] hms1: <Corsair CORSAIR K70 MAX RGB Magnetic-Mechanical Gaming Keyboard Mouse> on hidbus4
kernel: [45] hms1: 8 buttons and [XYW] coordinates ID=0

Now there is no /dev/sysmouse and no moused. The keyboard still has no working shift key. If I then unplug and plug the
keyboard back in in this state, I get the shift key to work.

Here's an /etc/X11/xorg.conf snippet:

Section "ServerFlags"
Option "AutoAddDevices" "False"
EndSection

Section "Files"
EndSection

Section "InputDevice"
# generated from default
Identifier "Mouse0"
Driver "mouse"
Option "Protocol" "auto"
Option "Device" "/dev/sysmouse"
Option "Emulate3Buttons" "no"
Option "ZAxisMapping" "4 5"
Option "Buttons" "10"
EndSection

As you can see from this, I would need /dev/sysmouse to work to get Xorg to see the mouse. I looked for a /dev/hms0 but didn't find one, so I've no idea what device to use in the above xorg config.

What I do now is to boot in with hw.usb.usbhid.enable=0, connect remotely, set hw.usb.usbhid.enable=1 and then replug the keyboard in. With this, I have a usable desktop system. This is not ideal at all.

I have so many questions, but I'll ask just two for now.

  1. Why is this all happening?
  2. What is the best way to fix it?
Thanks in advance for cogent replies.
 
/dev/sysmouse is disabled by default since 2020. /dev/input/event# is used instead of it. /dev/input/event# devices are handled by x11-drivers/xf86-input-libinput and autoconfigurable. No need to add any snippets to /etc/X11/xorg.conf.
If you need mouse pointer working in console. You have to use moused from 15.0. Old standalone version of it can be found here: https://github.com/wulf7/moused
 
/dev/sysmouse is disabled by default since 2020.

Where would I have found out about this and why (if it's disabled) is it being enabled anyway?

/dev/input/event# is used instead of it. /dev/input/event# devices are handled by x11-drivers/xf86-input-libinput and autoconfigurable. No need to add any snippets to /etc/X11/xorg.conf.

I saw those using
Code:
libinput debug-events
and yet I have no idea how to make xorg work with this ... what do I delete? The entire "InputDevice" section? Will this still map button 4 and 5?

If you need mouse pointer working in console. You have to use moused from 15.0. Old standalone version of it can be found here: https://github.com/wulf7/moused
I dont need a mouse in the console. :)
 
> Where would I have found out about this and why (if it's disabled) is it being enabled anyway?
I do not know. No one posts about "successful autoconnection of my mice" so such a things mostly come in background with no public impact.
Input devices autoconfiguration was supported by FreeBSD long before /dev/sysmouse had been disabled. So currently most info about FreeBSD input looks stalled.

> and yet I have no idea how to make xorg work with this ...
just install x11-drivers/xf86-input-libinput

> what do I delete? The entire "InputDevice" section? Will this still map button 4 and 5?
Delete the entire /etc/X11/xorg.conf. Novadays it is used to add a quirks only. In most cases autoconfiguration should just work.
 
Novadays it is used to add a quirks only.
Inaccurate.
At least legacy versions of nvidia drivers that are not supported by any of graphics/nvidia-drm-*-kmod[-devel] needs it, regardless legacy monolithic one or fine-grained modern ones.
This is because x11-servers/xorg-server does NOT know about proprietary nvidia drivers and always looks for old x11-drivers/xf86-video-nv or (nonexistent on FreeBSD) nouveau drivers only without manually (or semi-automated by x11/nvidia-xconfig) generated config file(s).
 
It would seem that I need at least the Nvidia config. I have seen other articles claim "just remove the entire xorg.conf" but I've never seen this work, perhaps because I use nvidia cards.
 
Back
Top