Key_NonUSPound doesn't print anything #273
Comments
|
Just in case: that should be |
|
I can confirm that |
|
Could this be an OS keymap issue? The key in question is between |
|
@mattvenn said it works on another keyboard of his. I'm now verifying if it is in the report, then will check OS keymap. That was my first suspicion too, but if it works on another board...? |
|
I can verify that the key correctly ends up in the report, so this is likely an OS-side issue. |
|
Ooon the other hand, the same code on the ErgoDox EZ works, with the same OS keymap. So perhaps there IS something on the firmware side that we can do. I suspect HID Descriptors. |
|
Mind you, using an US QWERTY OS layout, it comes across as |
|
https://github.com/keyboardio/KeyboardioHID/blob/master/src/MultiReport/Keyboard.cpp#L59
This is something we inherited from the driver we learned our
cross-platform NKRO tricks from.
…On Wed, Dec 20, 2017 at 1:19 PM, Gergely Nagy ***@***.***> wrote:
Mind you, using an US QWERTY OS layout, it comes across as \. Using US
International, it becomes #. However, \ becomes # on US International too.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#273 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AACxaB0wKTlcizJIqr6NykCZztrxEpoXks5tCXnQgaJpZM4RIzEf>
.
|
From KeyboardioHID. I'll have a go at removing this, and merging the usages. That should fix this issue, and make our descriptor a few bytes smaller too. |
|
On Dec 20, 2017, at 1:37 PM, Gergely Nagy ***@***.***> wrote:
// Padding 3 bits
// To skip HID_KEYBOARD_NON_US_POUND_AND_TILDE, which causes
// Linux to choke on our driver.
From KeyboardioHID.
I'll have a go at removing this, and merging the usages. That should fix this issue, and make our descriptor a few bytes smaller too.
Er. It will need extensive testing on a range of linuxes and androids. What @triplehaata told me was that without that skip, some linux kernels don’t cope with our driver.
… —
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
|
|
I tested Linux 2.6.32, 3.something, 4.9, and they all work the same way: they detect the keyboard, everything works. So I couldn't make the kernel choke on it, nor was I able to trigger double presses or anything like it. These issues would only occur if the keys in question were on the keymap. The Model01 factory firmware has neither. So I think not skipping But to be sure, I'll look into the linux kernel too. |
|
I'm on Ubuntu 16
…On 20 Dec 2017 10:09 p.m., "Gergely Nagy" ***@***.***> wrote:
I can verify that the key correctly ends up in the report, so this is
likely an OS-side issue.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#273 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAmtbBdedTi8HTQqLBMVybzjF2dKTE45ks5tCXeQgaJpZM4RIzEf>
.
|
|
keyboardio/KeyboardioHID#23 should have a "fix" then. Mind you, Linux will treat This is something deeply rooted in the kernel, something that has been there for at least 13 years. Changing it to treat the two separately would require change to the kernel, and everything above it to support it. The chances of that happening in my lifetime are slim to none, I believe. |
|
My \ key now is printing #. Maybe that happened as a result of keyboardio/KeyboardioHID#23. So then I used a key with no assigned keycode and used xmodmap to map it to . So now I have both! |
|
I think we can safely close this now. |
To be able to send NONUS_POUND and CLEAR keycodes, we need our report bitmap to support them, and not mask them over with constants. These were originally masked due to bugs in the Linux kernel: it treats NONUS_POUND the same as BACKSLASH, and CLEAR the same as DELETE. There is no way for userland to distinguish the two under Linux. But this is a linux-specific issue, one that is not relevant when neither NONUS_POUND or CLEAR appear on the keymap. Linux will happily accept a descriptor that does not mask this out (even ancient versions, going back 13 years). It will not double-press if these appear in the report. At worst, repeat will kick in faster if both BACKSLASH and NONUS_POUND are held at the same time. However, other OSes may - and do - work differently, and some of them handle NONUS_POUND separately from BACKSLASH. Because not masking out these keys in the report causes no issues under Linux (the only reason for the mask) unless the keys are in the report, and even then, the issue is not critical, we should not punish other operating systems. Linux has had this issue for at least 13 years (7 for CLEAR/DELETE). Changing it would require changes to the kernel and a whole lot of userland too. I do not see that happening in my lifetime, and that's even more reason for not waiting for Linux to get rid of the bug before changing the descriptors. Therefore, this patch removes the mask, and only the first four bits remain masked. Therefore, operating systems that can treat NONUS_POUND and CLEAR separately from BACKSLASH and DELETE will be able to do that, and Linux will not be severely impacted either. And we also save a few bytes. Fixes #273. Signed-off-by: Gergely Nagy <[email protected]>
To be able to send NONUS_POUND and CLEAR keycodes, we need our report bitmap to support them, and not mask them over with constants. These were originally masked due to bugs in the Linux kernel: it treats NONUS_POUND the same as BACKSLASH, and CLEAR the same as DELETE. There is no way for userland to distinguish the two under Linux. But this is a linux-specific issue, one that is not relevant when neither NONUS_POUND or CLEAR appear on the keymap. Linux will happily accept a descriptor that does not mask this out (even ancient versions, going back 13 years). It will not double-press if these appear in the report. At worst, repeat will kick in faster if both BACKSLASH and NONUS_POUND are held at the same time. However, other OSes may - and do - work differently, and some of them handle NONUS_POUND separately from BACKSLASH. Because not masking out these keys in the report causes no issues under Linux (the only reason for the mask) unless the keys are in the report, and even then, the issue is not critical, we should not punish other operating systems. Linux has had this issue for at least 13 years (7 for CLEAR/DELETE). Changing it would require changes to the kernel and a whole lot of userland too. I do not see that happening in my lifetime, and that's even more reason for not waiting for Linux to get rid of the bug before changing the descriptors. Therefore, this patch removes the mask, and only the first four bits remain masked. Therefore, operating systems that can treat NONUS_POUND and CLEAR separately from BACKSLASH and DELETE will be able to do that, and Linux will not be severely impacted either. And we also save a few bytes. Fixes #273. Signed-off-by: Gergely Nagy <[email protected]>
I want to print the # and ~ characters. xev shows nothing when the key is pressed.
The text was updated successfully, but these errors were encountered: