| Message ID | 20250311180643.1107430-2-wse@tuxedocomputers.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [v2,1/2] Input: atkbd - Map FN-key for TongFang barebones | expand |
Hi, On 11-Mar-25 19:10, Werner Sembach wrote: > Hi Hans, Hi Dimitry, > > resending this too on the v2 to not cause confusion: > > Regarding remapping KEY_ZENKAKUHANKAKU to KEY_TOUCHPAD_TOGGLE: > > Am 11.03.25 um 19:06 schrieb Werner Sembach: >> Currently only F23 is correctly mapped for PS/2 keyboards. >> >> Following to this table: >> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf >> >> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world >> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the >> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is >> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway. > > I think what the firmware vendor actually wanted to do was to send ctrl+super+f24 upon touchpad toggle. This would somewhat fall in line with, for example, the copilot key being implemented as shift+super+f23. I agree that that seems to be the intent. > Following this, my suggestion is to do this remapping and handle the rest in xkeyboard-config xkeyboard config already contains mappings for F13 - F18 and F20-F23 in /usr/share/X11/xkb/symbols/inet So all that needs to happen there is map FK19 -> F19 and FK24 -> F24. And then teach KDE + GNOME that ctrl+super+f24 means touchpad-toggle. We could maybe get away with also dropping the weird mappings for FK13 - FK18 and map those straight to F13 - F18, but we need the special mappings for F20 - F23 to stay in place to not break stuff. Regards, Hans
Hi again, Am 17.03.25 um 13:06 schrieb Hans de Goede: > Hi, > > On 11-Mar-25 19:10, Werner Sembach wrote: >> Hi Hans, Hi Dimitry, >> >> resending this too on the v2 to not cause confusion: >> >> Regarding remapping KEY_ZENKAKUHANKAKU to KEY_TOUCHPAD_TOGGLE: >> >> Am 11.03.25 um 19:06 schrieb Werner Sembach: >>> Currently only F23 is correctly mapped for PS/2 keyboards. >>> >>> Following to this table: >>> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf >>> >>> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world >>> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the >>> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is >>> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway. >> I think what the firmware vendor actually wanted to do was to send ctrl+super+f24 upon touchpad toggle. This would somewhat fall in line with, for example, the copilot key being implemented as shift+super+f23. > I agree that that seems to be the intent. > >> Following this, my suggestion is to do this remapping and handle the rest in xkeyboard-config > xkeyboard config already contains mappings for F13 - F18 and F20-F23 in > /usr/share/X11/xkb/symbols/inet > > So all that needs to happen there is map FK19 -> F19 and FK24 -> F24. > > And then teach KDE + GNOME that ctrl+super+f24 means touchpad-toggle. Alternative suggestion, again following how the copilot key is implemented: key <FK19> { [ F19 ] }; [...] key <FK23> { [ XF86TouchpadOff, XF86Assistant ], type[Group1] = "PC_SHIFT_SUPER_LEVEL2" }; key <FK24> { [ F24, XF86TouchpadToggle ], type[Group1] = "PC_CONTROL_SUPER_LEVEL2" }; Then only xkb has to be touched again, but not KDE and GNOME. > > We could maybe get away with also dropping the weird mappings for FK13 - FK18 > and map those straight to F13 - F18, but we need the special mappings > for F20 - F23 to stay in place to not break stuff. Good question XF86Tools launches system settings on KDE. XF86Launch5-9 do nothing by default afaict. Looking at the links in the git log of xkeyboard-config (commit 1e94d48801bf8cb75741aa308d4cdfb63b03c66c and 01d742bc5cd22543d21edb2101fec6558d4075db) these seems to be device specific bindings that got accepted in the default config because the keys where unbound before. Best regards, Werner > > Regards, > > Hans > >
Hi, Am 17.03.25 um 12:58 schrieb Hans de Goede: > Hi Werner, > > On 11-Mar-25 19:06, Werner Sembach wrote: >> Currently only F23 is correctly mapped for PS/2 keyboards. >> >> Following to this table: >> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf > That is a very interesting document, good find! > >> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world >> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the >> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is >> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway. >> >> * Qt on Wayland and therefore KDE on Wayland can see the keypress anyway for >> some reason and it is actually used in a touchpad toggle shortcut, but this is >> currently being fixed in both KDE and xkeyboard-config to make this less weird, >> so it could directly be fixed to correctly handle the F24 keypress instead. >> >> - The scancodes for F13-F22 are currently unmapped so there will probably be no >> harm in mapping them. This would also fix the issue that some of these keys >> can't be mapped as the target from userspace using the `setkeycodes` command. >> >> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> > Thanks, patch looks good to me: > > Reviewed-by: Hans de Goede <hdegoede@redhat.com> Thanks for reviewing. Should I resend the patch standalone because the first of this Patchset will likely be rejected? Best regards, Werner > > It is unfortunate that this changes the scancode 0x5f mapping from 85 to 194 > (from KEY_ZENKAKUHANKAKU to KEY_F24) but as you mention the xkbconfig does > not even define a keycode-label for 85 + 8 = 93 (xkb shifts all codes up 8) in: > /usr/share/X11/xkb/keycodes/evdev, 93 is simply not there. So making this changes > and updating the mapping to match the mappings from the microsoft document from > above sounds good to me. > > Regards, > > Hans > > > > >> --- >> drivers/input/keyboard/atkbd.c | 12 ++++++------ >> 1 file changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c >> index 3598a21d9d014..4bd6e6ef0715e 100644 >> --- a/drivers/input/keyboard/atkbd.c >> +++ b/drivers/input/keyboard/atkbd.c >> @@ -84,12 +84,12 @@ static const unsigned short atkbd_set2_keycode[ATKBD_KEYMAP_SIZE] = { >> #include "hpps2atkbd.h" /* include the keyboard scancodes */ >> >> #else >> - 0, 67, 65, 63, 61, 59, 60, 88, 0, 68, 66, 64, 62, 15, 41,117, >> - 0, 56, 42, 93, 29, 16, 2, 0, 0, 0, 44, 31, 30, 17, 3, 0, >> - 0, 46, 45, 32, 18, 5, 4, 95, 0, 57, 47, 33, 20, 19, 6,183, >> - 0, 49, 48, 35, 34, 21, 7,184, 0, 0, 50, 36, 22, 8, 9,185, >> - 0, 51, 37, 23, 24, 11, 10, 0, 0, 52, 53, 38, 39, 25, 12, 0, >> - 0, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0, 85, >> + 0, 67, 65, 63, 61, 59, 60, 88,183, 68, 66, 64, 62, 15, 41,117, >> + 184, 56, 42, 93, 29, 16, 2, 0,185, 0, 44, 31, 30, 17, 3, 0, >> + 186, 46, 45, 32, 18, 5, 4, 95,187, 57, 47, 33, 20, 19, 6,183, >> + 188, 49, 48, 35, 34, 21, 7,184,189, 0, 50, 36, 22, 8, 9,185, >> + 190, 51, 37, 23, 24, 11, 10, 0,191, 52, 53, 38, 39, 25, 12, 0, >> + 192, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0,194, >> 0, 86, 91, 90, 92, 0, 14, 94, 0, 79,124, 75, 71,121, 0, 0, >> 82, 83, 80, 76, 77, 72, 1, 69, 87, 78, 81, 74, 55, 73, 70, 99, >>
Hi, On 17-Mar-25 5:47 PM, Werner Sembach wrote: > Hi again, > > Am 17.03.25 um 13:06 schrieb Hans de Goede: >> Hi, >> >> On 11-Mar-25 19:10, Werner Sembach wrote: >>> Hi Hans, Hi Dimitry, >>> >>> resending this too on the v2 to not cause confusion: >>> >>> Regarding remapping KEY_ZENKAKUHANKAKU to KEY_TOUCHPAD_TOGGLE: >>> >>> Am 11.03.25 um 19:06 schrieb Werner Sembach: >>>> Currently only F23 is correctly mapped for PS/2 keyboards. >>>> >>>> Following to this table: >>>> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf >>>> >>>> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world >>>> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the >>>> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is >>>> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway. >>> I think what the firmware vendor actually wanted to do was to send ctrl+super+f24 upon touchpad toggle. This would somewhat fall in line with, for example, the copilot key being implemented as shift+super+f23. >> I agree that that seems to be the intent. >> >>> Following this, my suggestion is to do this remapping and handle the rest in xkeyboard-config >> xkeyboard config already contains mappings for F13 - F18 and F20-F23 in >> /usr/share/X11/xkb/symbols/inet >> >> So all that needs to happen there is map FK19 -> F19 and FK24 -> F24. >> >> And then teach KDE + GNOME that ctrl+super+f24 means touchpad-toggle. > > Alternative suggestion, again following how the copilot key is implemented: > > key <FK19> { [ F19 ] }; > [...] > key <FK23> { [ XF86TouchpadOff, XF86Assistant ], type[Group1] = "PC_SHIFT_SUPER_LEVEL2" }; > key <FK24> { [ F24, XF86TouchpadToggle ], type[Group1] = "PC_CONTROL_SUPER_LEVEL2" }; > > Then only xkb has to be touched again, but not KDE and GNOME. Ah I did not know you could do this. Yes this sounds like a very good plan wrt the xkbconfig changes and then indeed we can do all the handling in xkbconfig. > >> >> We could maybe get away with also dropping the weird mappings for FK13 - FK18 >> and map those straight to F13 - F18, but we need the special mappings >> for F20 - F23 to stay in place to not break stuff. > > Good question > > XF86Tools launches system settings on KDE. Right, but XF86Tools is also send for KEY_CONFIG which makes more sense, the question is are there any devices actually sending KEY_F13 in a case where they really should be sending KEY_CONFIG instead. Note this is unrelated to the XF86TouchpadToggle thing though, just something which I noticed while looking at things. > Looking at the links in the git log of xkeyboard-config (commit 1e94d48801bf8cb75741aa308d4cdfb63b03c66c and 01d742bc5cd22543d21edb2101fec6558d4075db) these seems to be device specific bindings that got accepted in the default config because the keys where unbound before. I see, so it might be worthwhile to try and fix these, but in a separate pull-request from the: key <FK24> { [ F24, XF86TouchpadToggle ], type[Group1] = "PC_CONTROL_SUPER_LEVEL2" }; addition. Regards, Hans
Hi Werner, On 17-Mar-25 6:00 PM, Werner Sembach wrote: > Hi, > > Am 17.03.25 um 12:58 schrieb Hans de Goede: >> Hi Werner, >> >> On 11-Mar-25 19:06, Werner Sembach wrote: >>> Currently only F23 is correctly mapped for PS/2 keyboards. >>> >>> Following to this table: >>> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf >> That is a very interesting document, good find! >> >>> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world >>> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the >>> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is >>> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway. >>> >>> * Qt on Wayland and therefore KDE on Wayland can see the keypress anyway for >>> some reason and it is actually used in a touchpad toggle shortcut, but this is >>> currently being fixed in both KDE and xkeyboard-config to make this less weird, >>> so it could directly be fixed to correctly handle the F24 keypress instead. >>> >>> - The scancodes for F13-F22 are currently unmapped so there will probably be no >>> harm in mapping them. This would also fix the issue that some of these keys >>> can't be mapped as the target from userspace using the `setkeycodes` command. >>> >>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> >> Thanks, patch looks good to me: >> >> Reviewed-by: Hans de Goede <hdegoede@redhat.com> > > Thanks for reviewing. > > Should I resend the patch standalone because the first of this Patchset will likely be rejected? I think this one will apply cleanly without applying patch 1/2 first, so no reason for a resend / v3 AFAICT. Let's wait and see what feedback Dmitry have once he can make some time to take a look at this. Regards, Hans >>> --- >>> drivers/input/keyboard/atkbd.c | 12 ++++++------ >>> 1 file changed, 6 insertions(+), 6 deletions(-) >>> >>> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c >>> index 3598a21d9d014..4bd6e6ef0715e 100644 >>> --- a/drivers/input/keyboard/atkbd.c >>> +++ b/drivers/input/keyboard/atkbd.c >>> @@ -84,12 +84,12 @@ static const unsigned short atkbd_set2_keycode[ATKBD_KEYMAP_SIZE] = { >>> #include "hpps2atkbd.h" /* include the keyboard scancodes */ >>> #else >>> - 0, 67, 65, 63, 61, 59, 60, 88, 0, 68, 66, 64, 62, 15, 41,117, >>> - 0, 56, 42, 93, 29, 16, 2, 0, 0, 0, 44, 31, 30, 17, 3, 0, >>> - 0, 46, 45, 32, 18, 5, 4, 95, 0, 57, 47, 33, 20, 19, 6,183, >>> - 0, 49, 48, 35, 34, 21, 7,184, 0, 0, 50, 36, 22, 8, 9,185, >>> - 0, 51, 37, 23, 24, 11, 10, 0, 0, 52, 53, 38, 39, 25, 12, 0, >>> - 0, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0, 85, >>> + 0, 67, 65, 63, 61, 59, 60, 88,183, 68, 66, 64, 62, 15, 41,117, >>> + 184, 56, 42, 93, 29, 16, 2, 0,185, 0, 44, 31, 30, 17, 3, 0, >>> + 186, 46, 45, 32, 18, 5, 4, 95,187, 57, 47, 33, 20, 19, 6,183, >>> + 188, 49, 48, 35, 34, 21, 7,184,189, 0, 50, 36, 22, 8, 9,185, >>> + 190, 51, 37, 23, 24, 11, 10, 0,191, 52, 53, 38, 39, 25, 12, 0, >>> + 192, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0,194, >>> 0, 86, 91, 90, 92, 0, 14, 94, 0, 79,124, 75, 71,121, 0, 0, >>> 82, 83, 80, 76, 77, 72, 1, 69, 87, 78, 81, 74, 55, 73, 70, 99, >>> >
Hi Hans Am 17.03.25 um 23:22 schrieb Hans de Goede: > Hi, > > On 17-Mar-25 5:47 PM, Werner Sembach wrote: >> Hi again, >> >> Am 17.03.25 um 13:06 schrieb Hans de Goede: >>> Hi, >>> >>> On 11-Mar-25 19:10, Werner Sembach wrote: >>>> Hi Hans, Hi Dimitry, >>>> >>>> resending this too on the v2 to not cause confusion: >>>> >>>> Regarding remapping KEY_ZENKAKUHANKAKU to KEY_TOUCHPAD_TOGGLE: >>>> >>>> Am 11.03.25 um 19:06 schrieb Werner Sembach: >>>>> Currently only F23 is correctly mapped for PS/2 keyboards. >>>>> >>>>> Following to this table: >>>>> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf >>>>> >>>>> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world >>>>> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the >>>>> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is >>>>> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway. >>>> I think what the firmware vendor actually wanted to do was to send ctrl+super+f24 upon touchpad toggle. This would somewhat fall in line with, for example, the copilot key being implemented as shift+super+f23. >>> I agree that that seems to be the intent. >>> >>>> Following this, my suggestion is to do this remapping and handle the rest in xkeyboard-config >>> xkeyboard config already contains mappings for F13 - F18 and F20-F23 in >>> /usr/share/X11/xkb/symbols/inet >>> >>> So all that needs to happen there is map FK19 -> F19 and FK24 -> F24. >>> >>> And then teach KDE + GNOME that ctrl+super+f24 means touchpad-toggle. >> Alternative suggestion, again following how the copilot key is implemented: >> >> key <FK19> { [ F19 ] }; >> [...] >> key <FK23> { [ XF86TouchpadOff, XF86Assistant ], type[Group1] = "PC_SHIFT_SUPER_LEVEL2" }; >> key <FK24> { [ F24, XF86TouchpadToggle ], type[Group1] = "PC_CONTROL_SUPER_LEVEL2" }; >> >> Then only xkb has to be touched again, but not KDE and GNOME. > Ah I did not know you could do this. Yes this sounds like a very good > plan wrt the xkbconfig changes and then indeed we can do all the handling > in xkbconfig. > > >>> We could maybe get away with also dropping the weird mappings for FK13 - FK18 >>> and map those straight to F13 - F18, but we need the special mappings >>> for F20 - F23 to stay in place to not break stuff. >> Good question >> >> XF86Tools launches system settings on KDE. > Right, but XF86Tools is also send for KEY_CONFIG which makes more sense, > the question is are there any devices actually sending KEY_F13 in > a case where they really should be sending KEY_CONFIG instead. > > Note this is unrelated to the XF86TouchpadToggle thing though, just > something which I noticed while looking at things. > >> Looking at the links in the git log of xkeyboard-config (commit 1e94d48801bf8cb75741aa308d4cdfb63b03c66c and 01d742bc5cd22543d21edb2101fec6558d4075db) these seems to be device specific bindings that got accepted in the default config because the keys where unbound before. > I see, so it might be worthwhile to try and fix these, but in > a separate pull-request from the: > > key <FK24> { [ F24, XF86TouchpadToggle ], type[Group1] = "PC_CONTROL_SUPER_LEVEL2" }; ack, I will create a MR as soon as the freedesktop gitlab migration is finished. Best regards, Werner > > addition. > > Regards, > > Hans > >
Hi, Am 17.03.25 um 23:23 schrieb Hans de Goede: > Hi Werner, > > On 17-Mar-25 6:00 PM, Werner Sembach wrote: >> Hi, >> >> Am 17.03.25 um 12:58 schrieb Hans de Goede: >>> Hi Werner, >>> >>> On 11-Mar-25 19:06, Werner Sembach wrote: >>>> Currently only F23 is correctly mapped for PS/2 keyboards. >>>> >>>> Following to this table: >>>> https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf >>> That is a very interesting document, good find! >>> >>>> - F24 and Zenkaku/Hankaku share the same scancode, but since in real world >>>> Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the >>>> scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is >>>> currently not bound in xkeyboard-config, so it is (mostly*) unused anyway. >>>> >>>> * Qt on Wayland and therefore KDE on Wayland can see the keypress anyway for >>>> some reason and it is actually used in a touchpad toggle shortcut, but this is >>>> currently being fixed in both KDE and xkeyboard-config to make this less weird, >>>> so it could directly be fixed to correctly handle the F24 keypress instead. >>>> >>>> - The scancodes for F13-F22 are currently unmapped so there will probably be no >>>> harm in mapping them. This would also fix the issue that some of these keys >>>> can't be mapped as the target from userspace using the `setkeycodes` command. >>>> >>>> Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> >>> Thanks, patch looks good to me: >>> >>> Reviewed-by: Hans de Goede <hdegoede@redhat.com> >> Thanks for reviewing. >> >> Should I resend the patch standalone because the first of this Patchset will likely be rejected? > I think this one will apply cleanly without applying patch 1/2 > first, so no reason for a resend / v3 AFAICT. > > Let's wait and see what feedback Dmitry have once he can make > some time to take a look at this. Ack Best regards, Werner > > Regards, > > Hans > > > > >>>> --- >>>> drivers/input/keyboard/atkbd.c | 12 ++++++------ >>>> 1 file changed, 6 insertions(+), 6 deletions(-) >>>> >>>> diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c >>>> index 3598a21d9d014..4bd6e6ef0715e 100644 >>>> --- a/drivers/input/keyboard/atkbd.c >>>> +++ b/drivers/input/keyboard/atkbd.c >>>> @@ -84,12 +84,12 @@ static const unsigned short atkbd_set2_keycode[ATKBD_KEYMAP_SIZE] = { >>>> #include "hpps2atkbd.h" /* include the keyboard scancodes */ >>>> #else >>>> - 0, 67, 65, 63, 61, 59, 60, 88, 0, 68, 66, 64, 62, 15, 41,117, >>>> - 0, 56, 42, 93, 29, 16, 2, 0, 0, 0, 44, 31, 30, 17, 3, 0, >>>> - 0, 46, 45, 32, 18, 5, 4, 95, 0, 57, 47, 33, 20, 19, 6,183, >>>> - 0, 49, 48, 35, 34, 21, 7,184, 0, 0, 50, 36, 22, 8, 9,185, >>>> - 0, 51, 37, 23, 24, 11, 10, 0, 0, 52, 53, 38, 39, 25, 12, 0, >>>> - 0, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0, 85, >>>> + 0, 67, 65, 63, 61, 59, 60, 88,183, 68, 66, 64, 62, 15, 41,117, >>>> + 184, 56, 42, 93, 29, 16, 2, 0,185, 0, 44, 31, 30, 17, 3, 0, >>>> + 186, 46, 45, 32, 18, 5, 4, 95,187, 57, 47, 33, 20, 19, 6,183, >>>> + 188, 49, 48, 35, 34, 21, 7,184,189, 0, 50, 36, 22, 8, 9,185, >>>> + 190, 51, 37, 23, 24, 11, 10, 0,191, 52, 53, 38, 39, 25, 12, 0, >>>> + 192, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0,194, >>>> 0, 86, 91, 90, 92, 0, 14, 94, 0, 79,124, 75, 71,121, 0, 0, >>>> 82, 83, 80, 76, 77, 72, 1, 69, 87, 78, 81, 74, 55, 73, 70, 99, >>>>
diff --git a/drivers/input/keyboard/atkbd.c b/drivers/input/keyboard/atkbd.c index 3598a21d9d014..4bd6e6ef0715e 100644 --- a/drivers/input/keyboard/atkbd.c +++ b/drivers/input/keyboard/atkbd.c @@ -84,12 +84,12 @@ static const unsigned short atkbd_set2_keycode[ATKBD_KEYMAP_SIZE] = { #include "hpps2atkbd.h" /* include the keyboard scancodes */ #else - 0, 67, 65, 63, 61, 59, 60, 88, 0, 68, 66, 64, 62, 15, 41,117, - 0, 56, 42, 93, 29, 16, 2, 0, 0, 0, 44, 31, 30, 17, 3, 0, - 0, 46, 45, 32, 18, 5, 4, 95, 0, 57, 47, 33, 20, 19, 6,183, - 0, 49, 48, 35, 34, 21, 7,184, 0, 0, 50, 36, 22, 8, 9,185, - 0, 51, 37, 23, 24, 11, 10, 0, 0, 52, 53, 38, 39, 25, 12, 0, - 0, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0, 85, + 0, 67, 65, 63, 61, 59, 60, 88,183, 68, 66, 64, 62, 15, 41,117, + 184, 56, 42, 93, 29, 16, 2, 0,185, 0, 44, 31, 30, 17, 3, 0, + 186, 46, 45, 32, 18, 5, 4, 95,187, 57, 47, 33, 20, 19, 6,183, + 188, 49, 48, 35, 34, 21, 7,184,189, 0, 50, 36, 22, 8, 9,185, + 190, 51, 37, 23, 24, 11, 10, 0,191, 52, 53, 38, 39, 25, 12, 0, + 192, 89, 40, 0, 26, 13, 0,193, 58, 54, 28, 27, 0, 43, 0,194, 0, 86, 91, 90, 92, 0, 14, 94, 0, 79,124, 75, 71,121, 0, 0, 82, 83, 80, 76, 77, 72, 1, 69, 87, 78, 81, 74, 55, 73, 70, 99,
Currently only F23 is correctly mapped for PS/2 keyboards. Following to this table: https://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3456c/translate.pdf - F24 and Zenkaku/Hankaku share the same scancode, but since in real world Zenkaku/Hankaku keys seem to just use the tilde scancode, this patch binds the scancode to F24. Note that on userspace side the KEY_ZENKAKUHANKAKU keycode is currently not bound in xkeyboard-config, so it is (mostly*) unused anyway. * Qt on Wayland and therefore KDE on Wayland can see the keypress anyway for some reason and it is actually used in a touchpad toggle shortcut, but this is currently being fixed in both KDE and xkeyboard-config to make this less weird, so it could directly be fixed to correctly handle the F24 keypress instead. - The scancodes for F13-F22 are currently unmapped so there will probably be no harm in mapping them. This would also fix the issue that some of these keys can't be mapped as the target from userspace using the `setkeycodes` command. Signed-off-by: Werner Sembach <wse@tuxedocomputers.com> --- drivers/input/keyboard/atkbd.c | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-)