Hi!
Let me start by prefacing that this *could* be a bug in the particular device I'm using, so I hope I'm not wasting anyone's time. I would hope to collect more information in order to report the issue into the device's GitHub, if it turns out to be the culprit. But, on the off chance this is FreeBSD-related:
I have FreeBSD 14-RELEASE running on a Lenovo Thinkpad. The built-in touchpad works beautifully including taps, and a cheap USB travel mouse is working equally well even if plugged after the system is already up. But I recently acquired a DeskHop (a "hardware" implementation of Synergy/Barrier/InputLeap is the closest definition I could find - allows you to use 2 computers by just moving the pointer between their screens - https://github.com/hrvach/deskhop ).
When I plug it in, it's seen normally by the system:
ugen0.2: <Hrvoje Cavrak DeskHop Switch> at usbus0
ukbd0 on uhub1
ukbd0: <DeskHop Switch> on usbus0
kbd2 at ukbd0
ums0 on uhub1
ums0: <DeskHop Helper> on usbus0
ums0: 5 buttons and [XYZ] coordinates ID=5
ugen0.7: <MOSART Semi. 2.4G Keyboard Mouse> at usbus0
unfortunately in my X session (and also in my console) mouse movements are not registered in any way (except for one specific case I list later). A cheap USB travel mouse works in both cases. Both devices cause a /dev/umsX to be created. One particular noteworthy info about the DeskHop is that it registers as an absolute pointing device. In the author's own words on the DeskHop github:
"To get the mouse cursor to magically jump across, the mouse hid report descriptor was changed to use absolute coordinates and then the mouse reports (that still come in relative movements) accumulate internally, keeping the accurate tally on the position."
and I'm wondering if this could have any bearing on FreeBSD's inability to see its movements.
a usbconfig dump_curr_config_desc of the device gives me this output (sorry for the verbosity):
ugen0.2: <Hrvoje Cavrak DeskHop Switch> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
Configuration index 0
bLength = 0x0009
bDescriptorType = 0x0002
wTotalLength = 0x003b
bNumInterfaces = 0x0002
bConfigurationValue = 0x0001
iConfiguration = 0x0000 <no string>
bmAttributes = 0x00a0
bMaxPower = 0x00fa
Interface 0
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x0000
bAlternateSetting = 0x0000
bNumEndpoints = 0x0001
bInterfaceClass = 0x0003 <HID device>
bInterfaceSubClass = 0x0000
bInterfaceProtocol = 0x0000
iInterface = 0x0002 <DeskHop Switch>
Additional Descriptor
bLength = 0x09
bDescriptorType = 0x21
bDescriptorSubType = 0x11
RAW dump:
0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x05,
0x08 | 0x01
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0081 <IN>
bmAttributes = 0x0003 <INTERRUPT>
wMaxPacketSize = 0x0020
bInterval = 0x0001
bRefresh = 0x0000
bSynchAddress = 0x0000
Interface 1
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x0001
bAlternateSetting = 0x0000
bNumEndpoints = 0x0001
bInterfaceClass = 0x0003 <HID device>
bInterfaceSubClass = 0x0000
bInterfaceProtocol = 0x0000
iInterface = 0x0004 <DeskHop Helper>
Additional Descriptor
bLength = 0x09
bDescriptorType = 0x21
bDescriptorSubType = 0x11
RAW dump:
0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x48,
0x08 | 0x00
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0082 <IN>
bmAttributes = 0x0003 <INTERRUPT>
wMaxPacketSize = 0x0020
bInterval = 0x0001
bRefresh = 0x0000
bSynchAddress = 0x0000
and the relevant chunk of libinput list-devices is this:
Device: DeskHop Helper
Kernel: /dev/input/event8
Group: 10
Seat: seat0, default
Capabilities: pointer
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: disabled
Nat.scrolling: disabled
Middle emulation: disabled
Calibration: n/a
Scroll methods: button
Click methods: none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles: flat *adaptive custom
Rotation: 0.0
if I do a diff with the "normal" USB mouse I see that it appears as Group 10 instead of 3 (other than having a different /dev/input/eventX number) but I don't know whether this has any relevance.
Also, running libinput debug-events I see absolutely no events coming from it.
-----
Now the specific circumstance I mentioned in the title: The DeskHop has a special Gaming mode which switches impersonate a more "normal" mouse. In the author's words:
"If you're gaming, there is a chance your game might not work properly with absolute mouse mode. To address that issue, a gaming mode is introduced, toggled by LEFT CTRL + RIGHT SHIFT + G. When in gaming mode, you are locked to the current screen and your mouse behaves like a standard relative mouse. This should also fix various virtual machine issues, currently unsupported operating systems etc."
Activating this gaming mode (confirmed by the expected LED blink pattern) does _not_ cause FreeBSD to detect the mouse, even libinput debug-events sees absolutely no events.....but *disabling it afterwards* (which in theory just reverts to the absolute mode) suddenly works! The pointer moves, buttons work, scrollwheel works, libinput debug-events reports to every action.
-event8 POINTER_MOTION +24.795s 0.94/ 0.00 ( +3.00/ +0.00)
event8 POINTER_MOTION +24.797s 2.15/ 0.00 ( +2.00/ +0.00)
event8 POINTER_MOTION +24.801s 4.64/ 1.55 ( +3.00/ +1.00)
event8 POINTER_MOTION +24.805s 4.23/ 0.00 ( +3.00/ +0.00)
Now this would be a perfectly acceptable workaround, but unfortunately as soon as I move into the other computer (therefore switching the mouse and keyboard behind the DeskHop to that computer), the magic breaks FreeBSD sees no events again, at least until I repeat the Gaming mode ON/Gaming mode OFF thing.
There's a chance this is a bug in DeskHop but as it works in my other computer combinations (Windows, Linux (didn't try MacOS)) I am wondering if there is anything else which I could look into?
By the way: when I move the pointer into the FreeBSD screen, the keyboard behind the DeskHop works perfectly.
Let me start by prefacing that this *could* be a bug in the particular device I'm using, so I hope I'm not wasting anyone's time. I would hope to collect more information in order to report the issue into the device's GitHub, if it turns out to be the culprit. But, on the off chance this is FreeBSD-related:
I have FreeBSD 14-RELEASE running on a Lenovo Thinkpad. The built-in touchpad works beautifully including taps, and a cheap USB travel mouse is working equally well even if plugged after the system is already up. But I recently acquired a DeskHop (a "hardware" implementation of Synergy/Barrier/InputLeap is the closest definition I could find - allows you to use 2 computers by just moving the pointer between their screens - https://github.com/hrvach/deskhop ).
When I plug it in, it's seen normally by the system:
ugen0.2: <Hrvoje Cavrak DeskHop Switch> at usbus0
ukbd0 on uhub1
ukbd0: <DeskHop Switch> on usbus0
kbd2 at ukbd0
ums0 on uhub1
ums0: <DeskHop Helper> on usbus0
ums0: 5 buttons and [XYZ] coordinates ID=5
ugen0.7: <MOSART Semi. 2.4G Keyboard Mouse> at usbus0
unfortunately in my X session (and also in my console) mouse movements are not registered in any way (except for one specific case I list later). A cheap USB travel mouse works in both cases. Both devices cause a /dev/umsX to be created. One particular noteworthy info about the DeskHop is that it registers as an absolute pointing device. In the author's own words on the DeskHop github:
"To get the mouse cursor to magically jump across, the mouse hid report descriptor was changed to use absolute coordinates and then the mouse reports (that still come in relative movements) accumulate internally, keeping the accurate tally on the position."
and I'm wondering if this could have any bearing on FreeBSD's inability to see its movements.
a usbconfig dump_curr_config_desc of the device gives me this output (sorry for the verbosity):
ugen0.2: <Hrvoje Cavrak DeskHop Switch> at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (500mA)
Configuration index 0
bLength = 0x0009
bDescriptorType = 0x0002
wTotalLength = 0x003b
bNumInterfaces = 0x0002
bConfigurationValue = 0x0001
iConfiguration = 0x0000 <no string>
bmAttributes = 0x00a0
bMaxPower = 0x00fa
Interface 0
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x0000
bAlternateSetting = 0x0000
bNumEndpoints = 0x0001
bInterfaceClass = 0x0003 <HID device>
bInterfaceSubClass = 0x0000
bInterfaceProtocol = 0x0000
iInterface = 0x0002 <DeskHop Switch>
Additional Descriptor
bLength = 0x09
bDescriptorType = 0x21
bDescriptorSubType = 0x11
RAW dump:
0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x05,
0x08 | 0x01
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0081 <IN>
bmAttributes = 0x0003 <INTERRUPT>
wMaxPacketSize = 0x0020
bInterval = 0x0001
bRefresh = 0x0000
bSynchAddress = 0x0000
Interface 1
bLength = 0x0009
bDescriptorType = 0x0004
bInterfaceNumber = 0x0001
bAlternateSetting = 0x0000
bNumEndpoints = 0x0001
bInterfaceClass = 0x0003 <HID device>
bInterfaceSubClass = 0x0000
bInterfaceProtocol = 0x0000
iInterface = 0x0004 <DeskHop Helper>
Additional Descriptor
bLength = 0x09
bDescriptorType = 0x21
bDescriptorSubType = 0x11
RAW dump:
0x00 | 0x09, 0x21, 0x11, 0x01, 0x00, 0x01, 0x22, 0x48,
0x08 | 0x00
Endpoint 0
bLength = 0x0007
bDescriptorType = 0x0005
bEndpointAddress = 0x0082 <IN>
bmAttributes = 0x0003 <INTERRUPT>
wMaxPacketSize = 0x0020
bInterval = 0x0001
bRefresh = 0x0000
bSynchAddress = 0x0000
and the relevant chunk of libinput list-devices is this:
Device: DeskHop Helper
Kernel: /dev/input/event8
Group: 10
Seat: seat0, default
Capabilities: pointer
Tap-to-click: n/a
Tap-and-drag: n/a
Tap drag lock: n/a
Left-handed: disabled
Nat.scrolling: disabled
Middle emulation: disabled
Calibration: n/a
Scroll methods: button
Click methods: none
Disable-w-typing: n/a
Disable-w-trackpointing: n/a
Accel profiles: flat *adaptive custom
Rotation: 0.0
if I do a diff with the "normal" USB mouse I see that it appears as Group 10 instead of 3 (other than having a different /dev/input/eventX number) but I don't know whether this has any relevance.
Also, running libinput debug-events I see absolutely no events coming from it.
-----
Now the specific circumstance I mentioned in the title: The DeskHop has a special Gaming mode which switches impersonate a more "normal" mouse. In the author's words:
"If you're gaming, there is a chance your game might not work properly with absolute mouse mode. To address that issue, a gaming mode is introduced, toggled by LEFT CTRL + RIGHT SHIFT + G. When in gaming mode, you are locked to the current screen and your mouse behaves like a standard relative mouse. This should also fix various virtual machine issues, currently unsupported operating systems etc."
Activating this gaming mode (confirmed by the expected LED blink pattern) does _not_ cause FreeBSD to detect the mouse, even libinput debug-events sees absolutely no events.....but *disabling it afterwards* (which in theory just reverts to the absolute mode) suddenly works! The pointer moves, buttons work, scrollwheel works, libinput debug-events reports to every action.
-event8 POINTER_MOTION +24.795s 0.94/ 0.00 ( +3.00/ +0.00)
event8 POINTER_MOTION +24.797s 2.15/ 0.00 ( +2.00/ +0.00)
event8 POINTER_MOTION +24.801s 4.64/ 1.55 ( +3.00/ +1.00)
event8 POINTER_MOTION +24.805s 4.23/ 0.00 ( +3.00/ +0.00)
Now this would be a perfectly acceptable workaround, but unfortunately as soon as I move into the other computer (therefore switching the mouse and keyboard behind the DeskHop to that computer), the magic breaks FreeBSD sees no events again, at least until I repeat the Gaming mode ON/Gaming mode OFF thing.
There's a chance this is a bug in DeskHop but as it works in my other computer combinations (Windows, Linux (didn't try MacOS)) I am wondering if there is anything else which I could look into?
By the way: when I move the pointer into the FreeBSD screen, the keyboard behind the DeskHop works perfectly.
