Special keys do not work anymore #2213

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

And the update deletes old hotkeys.

@trudnorx commented on GitHub (May 21, 2021): And the update deletes old hotkeys.

deekerman commented

Author

Owner

@davidebeatrici commented on GitHub (May 21, 2021):

Old hotkeys are deleted because they are now saved differently (it depends on the backend), however all keys are supposed to appear because we're using raw input.

What keyboard is it?

@davidebeatrici commented on GitHub (May 21, 2021): Old hotkeys are deleted because they are now saved differently (it depends on the backend), however all keys are supposed to appear because we're using raw input. What keyboard is it?

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

I don't think it depends on keyboard model because this keyboard doesn't have any custom driver or anything. So probably just sends normal keycodes but ones that are not common.

And here's another issue: AppKeys are failing too -- getting detected as 'K0'.

So while special keys are not detected at all, "AppKeys" are all falsely detected as K0.

So you can test the second part of the issue with any keyboard that has AppKeys (home, search, calculator, etc. See list.). Or you could also send simulated key presses, I guess.

@trudnorx commented on GitHub (May 21, 2021): I don't think it depends on keyboard model because this keyboard doesn't have any custom driver or anything. So probably just sends normal keycodes but ones that are not common. And here's another issue: [AppKeys](https://duckduckgo.com/?q=appkey+windows) are failing too -- getting detected as 'K0'. So while special keys are not detected at all, "AppKeys" are all falsely detected as K0. So you can test the second part of the issue with any keyboard that has AppKeys (home, search, calculator, etc. [See list.](https://winaero.com/change-what-extra-app-keys-do-for-the-keyboard-in-windows-10-8-and-7/)). Or you could also send simulated key presses, I guess.

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

Volume up/down keys are falsely getting detected as K0. You can test that on almost any keyboard. Media play/pause key is not detected at all. Again, testable on almost any keyboard. Do any of these issues happen with yours?

@trudnorx commented on GitHub (May 21, 2021): Volume up/down keys are falsely getting detected as K0. You can test that on almost any keyboard. Media play/pause key is not detected at all. Again, testable on almost any keyboard. Do any of these issues happen with yours?

deekerman commented

Author

Owner

@davidebeatrici commented on GitHub (May 21, 2021):

App keys can be enabled by specifying RIDEV_APPKEYS when registering the raw input device: https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-rawinputdevice

The problem is that RIDEV_NOLEGACY has to be specified too and that causes input not to be registered by Qt anymore.

As a workaround we can handle WM_APPCOMMAND messages: https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-appcommand

@davidebeatrici commented on GitHub (May 21, 2021): App keys can be enabled by specifying `RIDEV_APPKEYS` when registering the raw input device: https://docs.microsoft.com/en-us/windows/win32/api/winuser/ns-winuser-rawinputdevice The problem is that `RIDEV_NOLEGACY` has to be specified too and that causes input not to be registered by Qt anymore. As a workaround we can handle `WM_APPCOMMAND` messages: https://docs.microsoft.com/en-us/windows/win32/inputdev/wm-appcommand

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

Actually it looks like media play/pause is detected as K0 too so it's not the same issue as the "special keys" that are not detected at all. Interestingly, however, media play/pause wasn't getting detected at all as long as another app was using it. Maybe the issues are linked. Maybe some app is using my special keys? Did Mumble go from being able to detect keys which are in use by other apps to not at all? Or maybe media play/pause is somehow 'exclusive' in a way other keys aren't.

@trudnorx commented on GitHub (May 21, 2021): Actually it looks like media play/pause is detected as K0 too so it's not the same issue as the "special keys" that are not detected at all. Interestingly, however, media play/pause wasn't getting detected at all as long as another app was using it. Maybe the issues are linked. Maybe some app is using my special keys? Did Mumble go from being able to detect keys which are in use by other apps to not at all? Or maybe media play/pause is somehow 'exclusive' in a way other keys aren't.

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

Testing reveals media play/pause key cannot be caught by WM_APPCOMMAND if it is in use by another application. Also, it cannot detect any of the 'special keys' I talked about at all. But this may be regular behavior because these may not be AppKeys.

Is your raw input code able to detect keycodes >255?

@trudnorx commented on GitHub (May 21, 2021): Testing reveals media play/pause key cannot be caught by WM_APPCOMMAND if it is in use by another application. Also, it cannot detect any of the 'special keys' I talked about at all. But this may be regular behavior because these may not be AppKeys. Is your raw input code able to detect keycodes >255?

deekerman commented

Author

Owner

@davidebeatrici commented on GitHub (May 21, 2021):

Yes, it's a 16 bit variable.

@davidebeatrici commented on GitHub (May 21, 2021): Yes, it's a 16 bit variable.

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

https://www.nirsoft.net/utils/keyboard_state_view.html is able to detect appkeys but none of the special keys. So fixing the appkeys issue won't necessarily fix the special keys, I guess.

@trudnorx commented on GitHub (May 21, 2021): https://www.nirsoft.net/utils/keyboard_state_view.html is able to detect appkeys but none of the special keys. So fixing the appkeys issue won't necessarily fix the special keys, I guess.

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

Looks like the keyboard registers as RIM_TYPEHID and sends the special keys through there, & other raw input programs are able to catch them, but for whatever reason the new Mumble isn't catching them.

@trudnorx commented on GitHub (May 21, 2021): Looks like the keyboard registers as RIM_TYPEHID and sends the special keys through there, & other raw input programs are able to catch them, but for whatever reason the new Mumble isn't catching them.

deekerman commented

Author

Owner

@davidebeatrici commented on GitHub (May 21, 2021):

The K prefix means that the packet is received as RIM_TYPEKEYBOARD.

With my keyboard multimedia keys appear as follows:

Stop: J
Reverse: Q
Play/Pause: G
Forward: P
Mail: 108
Home: M
Calculator: F
Volume-: C
Volume+: B
Mute: D

@davidebeatrici commented on GitHub (May 21, 2021): The `K` prefix means that the packet is received as `RIM_TYPEKEYBOARD`. With my keyboard multimedia keys appear as follows: - Stop: `J` - Reverse: `Q` - Play/Pause: `G` - Forward: `P` - Mail: `108` - Home: `M` - Calculator: `F` - Volume-: `C` - Volume+: `B` - Mute: `D`

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

The K prefix means that the packet is received as RIM_TYPEKEYBOARD.

Ok, but that's for AppKeys which are falsely detected as K0. What I defined as "special keys" (which excludes AppKeys, by my definition) is not detected at all, thus no K. And, after reading on the web, it seems that some keyboards establish a RIM_TYPEHID device, in addition to RIM_TYPEKEYBOARD, and send the 'special keys' through RIM_TYPEHID. I think that's what's happening here, because other raw input apps are detecting a RIM_TYPEHID and are detecting the special key presses there, yet new Mumble is not. (but old Mumble, before the implementation of raw input, was, as I explained)

Do you understand? And do you have any ideas what could be causing that?

@trudnorx commented on GitHub (May 21, 2021): > The `K` prefix means that the packet is received as `RIM_TYPEKEYBOARD`. Ok, but that's for AppKeys which are falsely detected as K0. What I defined as "special keys" (which excludes AppKeys, by my definition) is not detected at all, thus no K. And, after reading on the web, it seems that some keyboards establish a RIM_TYPEHID device, in addition to RIM_TYPEKEYBOARD, and send the 'special keys' through RIM_TYPEHID. I think that's what's happening here, because other raw input apps are detecting a RIM_TYPEHID *and* are detecting the special key presses there, yet new Mumble is not. (but old Mumble, before the implementation of raw input, was, as I explained) Do you understand? And do you have any ideas what could be causing that?

deekerman commented

Author

Owner

@davidebeatrici commented on GitHub (May 21, 2021):

Keyboards that define extra keys should indeed have an extra interface that is detected as RIM_TYPEHID.

What I don't understand is why in your case they appear as RIM_TYPEKEYBOARD.

Which raw input apps are working fine?

@davidebeatrici commented on GitHub (May 21, 2021): Keyboards that define extra keys should indeed have an extra interface that is detected as `RIM_TYPEHID`. What I don't understand is why in your case they appear as `RIM_TYPEKEYBOARD`. Which raw input apps are working fine?

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

Keyboards that define extra keys should indeed have an extra interface that is detected as RIM_TYPEHID.
What I don't understand is why in your case they appear as RIM_TYPEKEYBOARD.

I believe that you are not reading what I stated carefully enough. In my case, they are RIM_TYPEHID, and Mumble is not detecting them at all (neither as RIM_TYPEKEYBOARD nor as anything else). This is a different issue to my media keys being detected as RIM_TYPEKEYBOARD (but with the wrong keycode).

@trudnorx commented on GitHub (May 21, 2021): > Keyboards that define extra keys should indeed have an extra interface that is detected as `RIM_TYPEHID`. > What I don't understand is why in your case they appear as `RIM_TYPEKEYBOARD`. I believe that you are not reading what I stated carefully enough. In my case, they **are** RIM_TYPEHID, and Mumble is not detecting them **at all** (neither as RIM_TYPEKEYBOARD nor as anything else). This is a _different_ issue to my media keys being detected as RIM_TYPEKEYBOARD (but with the wrong keycode).

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

Let me attempt to clarify the discussion by stating the two issues clearly

Issue 1. My keyboard's extra keys, which are RIM_TYPEHID, show up in other raw input apps; but Mumble is completely unable to detect them; they show up as "No buttons assigned" (old Mumble, before raw input, was able to use them as shortcut).

Issue 2. AppKeys, e.g. volume up/down, are successfully detected by Mumble, but falsely all detected as "K0". Which is wrong because all of them end up triggering the same function instead of being able to assign them to different functions.

@trudnorx commented on GitHub (May 21, 2021): Let me attempt to clarify the discussion by stating the two issues clearly **Issue 1**. My keyboard's extra keys, which are RIM_TYPEHID, show up in other raw input apps; but Mumble is completely unable to detect them; they show up as "**No buttons assigned**" (old Mumble, before raw input, was able to use them as shortcut). **Issue 2**. AppKeys, e.g. volume up/down, are successfully detected by Mumble, but falsely all detected as "**K0**". Which is wrong because all of them end up triggering the same function instead of being able to assign them to different functions.

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

Do you want me to split these two issues by creating two different new threads?

@trudnorx commented on GitHub (May 21, 2021): Do you want me to split these two issues by creating two different new threads?

deekerman commented

Author

Owner

@davidebeatrici commented on GitHub (May 21, 2021):

No, it's fine.

Is the HID device detected in the developer console?

@davidebeatrici commented on GitHub (May 21, 2021): No, it's fine. Is the HID device detected in the developer console?

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

I did a DebugView (is that ok?) and I see nothing about HID or keyboards.

@trudnorx commented on GitHub (May 21, 2021): I did a DebugView (is that ok?) and I see nothing about HID or keyboards.

deekerman commented

Author

Owner

@davidebeatrici commented on GitHub (May 21, 2021):

I would use Mumble's console, just to be sure.

@davidebeatrici commented on GitHub (May 21, 2021): I would use Mumble's console, just to be sure.

deekerman commented

Author

Owner

@trudnorx commented on GitHub (May 21, 2021):

How do you enable it? I did DebugView because that's what I found when I googled "mumble console".

@trudnorx commented on GitHub (May 21, 2021): How do you enable it? I did DebugView because that's what I found when I googled "mumble console".

deekerman commented

Author

Owner

@davidebeatrici commented on GitHub (May 22, 2021):

Check "Enable Developer menu".

@davidebeatrici commented on GitHub (May 22, 2021): ![](https://user-images.githubusercontent.com/5897523/119214036-ec40f080-bac3-11eb-92f2-8dfd6eb04c1a.png) Check "Enable Developer menu". ![](https://user-images.githubusercontent.com/5897523/119214069-2f02c880-bac4-11eb-9abe-e4f943baffc6.png)

deekerman commented