-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
do not allow using keyboards and mice as HID controllers #4243
Conversation
Enabling a keyboard or mouse as an HID controller makes it stop working as a keyboard or mouse.
6594bc8
to
b4bfe76
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we have an exotic use case to use a second mouse for scratching. Can we preserve this without recompileing?
The root case for the linked issues seems that the mouse was enabled by default, the user setting was not persistent.
For my feeling this is the issue we should solve. Otherwise we need to Handel every single other issue of this type in our code base.
@@ -151,10 +151,8 @@ void HidController::guessDeviceCategory() { | |||
if (hid_interface_number==-1) { | |||
if (hid_usage_page==0x1) { | |||
switch (hid_usage) { | |||
case 0x2: info = tr("Generic HID Mouse"); break; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This change seem to be unrelated.
Now it runs to the default branch which is less describtive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These devices do not appear in the GUI because they are filtered out in HidEnumerator.
(device_info.usage == kGenericDesktopMouseUsage || | ||
device_info.usage == kGenericDesktopKeyboardUsage)) { | ||
return false; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we move this to the default deny list instead?
That would be the natural place.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried that at first but the backwards logic made it really confusing. I think this implementation is more straightforward. First there is this check for all mice and keyboards, then the denlylist is used to filter specific device models.
I don't really care. That user can comment out this code and recompile. I could even comment out the code myself, push it to a branch on GitHub, and the user could download the artifact. I am much more concerned about users accidentally getting their computer (not just Mixxx!) into an unusable state, which is much more common than exotic questionably useful hacks. https://bugs.launchpad.net/mixxx/+bug/1940599 is not the first time that has happened (I do not recall where a user has asked for help for this before, but I am pretty sure it has happened). If there was no downside to letting users treat mice and keyboards as HID DJ controllers, then yeah it'd be nice to let them do so. But the downside is that some users will get their computer into an unusable state and (rightfully IMO) blame Mixxx. |
That is a separate issue solved in #4244. The user who reported the bug was affected by both. |
Is this really something we should change in 2.3? |
Yes, this is a critical bug. The user can get their computer into an entirely unusable state so they have to restart it.
No, that is unrelated. |
It's not a regression from hidraw. I have a Ducky mecha mini keyboard which shows up as a HID controller and stopped working when I enabled it in the Mixxx preferences on 2.3. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am still not convinced of the scattered logic. But everything is well documented and we can't rewrite it for 2.3. Works for me.
Any objections? Otherwise let's merge. |
ping |
I interpret the lack of responses as silent approval. LGTM I will take care of merging into main. Already did this for testing, should not be difficult. |
Done. The constants have landed in hiddevice.h where they belong to instead of in hiddenylist.h. |
Btw, I can confirm that my laptops built-in touchpad doesn't show up anymore. 👍 |
Please attach the enumerated HID devices from the log file. |
|
Apple is likely to keep changing the product IDs of their laptop components over time. I suggest we disallow any HID device with Apple's vendor ID. Thoughts? |
Taking another look at the log you posted above, that device has a different vendor ID... |
Manufacturer: Apple | Product: Magic Trackpad 2 Right, so should that also be added to exclusion list? |
I suppose so. |
Enabling a keyboard or mouse as an HID controller makes it stop
working as a keyboard or mouse.