keyboard issues

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

keyboard issues

Stefan Niestegge-2
Hello,

on my Falcon i have the problem that under heavy load (like apt update)
moving the mouse often causes a key "hang" and repeat. Pressing
the space bar stops the repeating of the hanging key.

On an Atari, the mouse is connected to the keyboard, and produces
keyboard-like events. Moving a mousewheel is same as cursor up/down,
for example. I guess that the buffer overflows when CPU is occupied.

If someone has an idea how to prevent that, i'd be thankful.
But then, its not a showstopping issue. A 100& used CPU will probably
just fail to fetch the IKBD buffer in time.


The more serious problem i have is probably just a configuring issue.

Using dpk-reconfigure keyboard-configuration i can choose Atari TT
keyboard with my DE layout, which does pretty well.

In older X11 (XFree86) documentation, there is "ataritt" layout for X11.
The Debian sid we now work on does not know that layout and defaults to
PC105 even when my xorg.conf clearly defines ataritt.

The tool xev shows that cursor keys produce same keycodes as found
with numpad keys. I have not completely understood how that works,
or there is a more serious issue here.

With modifying my xmodmap i was able to get cursor keys, | and ~
working, but not the Alternate key. Without Alt, entering @ and many
other important sysmbos is not possible. I also need it to move
windows that have their title bars out of the screen.

I would also like to have an AltGr instead of the capslock.


Maybe someone here has some insight, or a good read for me.


Greetings, and thanks for reading,
Stefan

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Geert Uytterhoeven
Hi Stefan,

On Tue, Sep 4, 2018 at 11:21 PM Stefan Niestegge <[hidden email]> wrote:

> Using dpk-reconfigure keyboard-configuration i can choose Atari TT
> keyboard with my DE layout, which does pretty well.
>
> In older X11 (XFree86) documentation, there is "ataritt" layout for X11.
> The Debian sid we now work on does not know that layout and defaults to
> PC105 even when my xorg.conf clearly defines ataritt.
>
> The tool xev shows that cursor keys produce same keycodes as found
> with numpad keys. I have not completely understood how that works,
> or there is a more serious issue here.

It assumes a PC keyboard, and (nonexistent?) NumLock is turned off,
so 2/4/6/8 produce cursor events?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Michael Schmitz-4
In reply to this post by Stefan Niestegge-2
Stefan,

good to hear you got the TT to boot - what did you change in the boot
options BTW?


On 05/09/18 09:20, Stefan Niestegge wrote:
> Hello,
>
> on my Falcon i have the problem that under heavy load (like apt
> update) moving the mouse often causes a key "hang" and repeat. Pressing
> the space bar stops the repeating of the hanging key.

Keyboard interrupts can be locked out for long enough for the driver to
miss data. Apparently that does include crucial break codes.

Do you see any 'keyboard overrun' messages in the console logs?

> On an Atari, the mouse is connected to the keyboard, and produces
> keyboard-like events. Moving a mousewheel is same as cursor up/down,
> for example. I guess that the buffer overflows when CPU is occupied.
>
> If someone has an idea how to prevent that, i'd be thankful.
> But then, its not a showstopping issue. A 100& used CPU will probably
> just fail to fetch the IKBD buffer in time.

The keyboard driver already tries to resynchronize the packet stream if
it missed packets. Maybe we also need to synthesize a break code if the
last key event sent to the input layer was a make code. Look at the
state machine in arch/m68k/atari/atakeyb.c - line 163 says to skip this
byte which is certainly necessary, but maybe additionally you want to
check whether the previous keyboard state was KEYBOARD, and the
break_flag was clear, and send out an input event for the previous
scancode as key up event in that case . Need to keep track of the
previous scancode though, and it won't protect you from key repeats when
multiple keys were recorded as down at the time the overrun happens.

>
>
> The more serious problem i have is probably just a configuring issue.
>
> Using dpk-reconfigure keyboard-configuration i can choose Atari TT
> keyboard with my DE layout, which does pretty well.
>
> In older X11 (XFree86) documentation, there is "ataritt" layout for X11.
> The Debian sid we now work on does not know that layout and defaults to
> PC105 even when my xorg.conf clearly defines ataritt.

The old layout probably used the old Atari scancodes and would be
useless now. The Atari keyboard driver uses a hardcoded key map as found
in drivers/input/keyboard/atakbd.c (US layout) translating the Atari
scancodes to Linux keycodes which I worked out from some docs found on
the web, and logging raw scancodes on my Falcon. There are quite a few
scancodes that I wasn't sure about (see FIXME comments in same), patches
are welcome.

>
> The tool xev shows that cursor keys produce same keycodes as found
> with numpad keys. I have not completely understood how that works,
> or there is a more serious issue here.

That may be a result of the PC105 key map - key codes for cursor keys
and keypad keys are distinct in the Atari key map.

>
> With modifying my xmodmap i was able to get cursor keys, | and ~
> working, but not the Alternate key. Without Alt, entering @ and many
> other important sysmbos is not possible. I also need it to move
> windows that have their title bars out of the screen.
>
> I would also like to have an AltGr instead of the capslock.

There's no right Alt keycode in the map. Does the default keymap work on
the text console? I.e., do you get correct behaviour for Alt and
CapsLock there?

Maybe the TT needs a different default keymap. Edit the mapping in
drivers/input/keyboard/atakbd.c until you have something that works on
your TT keyboard (on the text console, mind you!) and submit that to
linux-m68k please.

To see the raw scancodes, add  a dprintk statement before line 198 in
drivers/input/keyboard/atakbd.c (make sure you can log in remotely to
change the console loglevel to enable/disable printing these messages!).

Cheers,

     Michael

>
>
> Maybe someone here has some insight, or a good read for me.
>
>
> Greetings, and thanks for reading,
> Stefan
>

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Stefan Niestegge-2


Am 05.09.2018 um 03:01 schrieb Michael Schmitz:
> Stefan,
>
> good to hear you got the TT to boot - what did you change in the boot
> options BTW?

No no, this is happening on my Falcon.

>
>
> On 05/09/18 09:20, Stefan Niestegge wrote:
>> Hello,
>>
>> on my Falcon i have the problem that under heavy load (like apt
>> update) moving the mouse often causes a key "hang" and repeat. Pressing
>> the space bar stops the repeating of the hanging key.
>
> Keyboard interrupts can be locked out for long enough for the driver to
> miss data. Apparently that does include crucial break codes.
>
> Do you see any 'keyboard overrun' messages in the console logs?

no, i just see whereever the cursor is, one character, repeating until i
hit space bar. can be on X11 or on the console.

>
>> On an Atari, the mouse is connected to the keyboard, and produces
>> keyboard-like events. Moving a mousewheel is same as cursor up/down,
>> for example. I guess that the buffer overflows when CPU is occupied.
>>
>> If someone has an idea how to prevent that, i'd be thankful.
>> But then, its not a showstopping issue. A 100& used CPU will probably
>> just fail to fetch the IKBD buffer in time.
>
> The keyboard driver already tries to resynchronize the packet stream if
> it missed packets. Maybe we also need to synthesize a break code if the
> last key event sent to the input layer was a make code. Look at the
> state machine in arch/m68k/atari/atakeyb.c - line 163 says to skip this
> byte which is certainly necessary, but maybe additionally you want to
> check whether the previous keyboard state was KEYBOARD, and the
> break_flag was clear, and send out an input event for the previous
> scancode as key up event in that case . Need to keep track of the
> previous scancode though, and it won't protect you from key repeats when
> multiple keys were recorded as down at the time the overrun happens.

You're assuming i understand code, which is not the case.

>
>>
>>
>> The more serious problem i have is probably just a configuring issue.
>>
>> Using dpk-reconfigure keyboard-configuration i can choose Atari TT
>> keyboard with my DE layout, which does pretty well.
>>
>> In older X11 (XFree86) documentation, there is "ataritt" layout for X11.
>> The Debian sid we now work on does not know that layout and defaults to
>> PC105 even when my xorg.conf clearly defines ataritt.
>
> The old layout probably used the old Atari scancodes and would be
> useless now. The Atari keyboard driver uses a hardcoded key map as found
> in drivers/input/keyboard/atakbd.c (US layout) translating the Atari
> scancodes to Linux keycodes which I worked out from some docs found on
> the web, and logging raw scancodes on my Falcon. There are quite a few
> scancodes that I wasn't sure about (see FIXME comments in same), patches
> are welcome.
>
So the fix lies in finishing atakbd.c? Xorg will still default to PC105,
won't it?

>>
>> The tool xev shows that cursor keys produce same keycodes as found
>> with numpad keys. I have not completely understood how that works,
>> or there is a more serious issue here.
>
> That may be a result of the PC105 key map - key codes for cursor keys
> and keypad keys are distinct in the Atari key map.

Geerts idea of numlock off explains it well.

>
>>
>> With modifying my xmodmap i was able to get cursor keys, | and ~
>> working, but not the Alternate key. Without Alt, entering @ and many
>> other important sysmbos is not possible. I also need it to move
>> windows that have their title bars out of the screen.
>>
>> I would also like to have an AltGr instead of the capslock.
>
> There's no right Alt keycode in the map. Does the default keymap work on
> the text console? I.e., do you get correct behaviour for Alt and
> CapsLock there?

Yes, i can switch VT from one to other, but not back from X11,
for example. CapsLock also working as desired.
>
> Maybe the TT needs a different default keymap. Edit the mapping in
> drivers/input/keyboard/atakbd.c until you have something that works on
> your TT keyboard (on the text console, mind you!) and submit that to
> linux-m68k please.
>
I am very confident that TT and Falcon do not differ here.

> To see the raw scancodes, add  a dprintk statement before line 198 in
> drivers/input/keyboard/atakbd.c (make sure you can log in remotely to
> change the console loglevel to enable/disable printing these messages!).

I can login via ssh, but i cannot compile the same kernel as provided
during install yet. Carsten will come over today, maybe we get it
running on the crosscompiler.

Greetings,
Stefan

>
> Cheers,
>
>      Michael
>
>>
>>
>> Maybe someone here has some insight, or a good read for me.
>>
>>
>> Greetings, and thanks for reading,
>> Stefan
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Stefan Niestegge-2
In reply to this post by Geert Uytterhoeven


Am 04.09.2018 um 23:28 schrieb Geert Uytterhoeven:

> Hi Stefan,
>
> On Tue, Sep 4, 2018 at 11:21 PM Stefan Niestegge <[hidden email]> wrote:
>> Using dpk-reconfigure keyboard-configuration i can choose Atari TT
>> keyboard with my DE layout, which does pretty well.
>>
>> In older X11 (XFree86) documentation, there is "ataritt" layout for X11.
>> The Debian sid we now work on does not know that layout and defaults to
>> PC105 even when my xorg.conf clearly defines ataritt.
>>
>> The tool xev shows that cursor keys produce same keycodes as found
>> with numpad keys. I have not completely understood how that works,
>> or there is a more serious issue here.
>
> It assumes a PC keyboard, and (nonexistent?) NumLock is turned off,
> so 2/4/6/8 produce cursor events?

Geert, this would explain it perfectly. I'll try to map numlock on
Ctrl+Undo or so.

Thanks,
Stefan

>
> Gr{oetje,eeting}s,
>
>                          Geert
>

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Geert Uytterhoeven
In reply to this post by Stefan Niestegge-2
Hi Stefan,

On Wed, Sep 5, 2018 at 8:11 AM Stefan Niestegge <[hidden email]> wrote:
> Am 05.09.2018 um 03:01 schrieb Michael Schmitz:
> > There's no right Alt keycode in the map. Does the default keymap work on
> > the text console? I.e., do you get correct behaviour for Alt and
> > CapsLock there?
>
> Yes, i can switch VT from one to other, but not back from X11,
> for example. CapsLock also working as desired.

Can you switch back from X11 using e.g. CTRL + ALT + F1
(CTRL is the key)?

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Stefan Niestegge-2


Am 05.09.2018 um 08:40 schrieb Geert Uytterhoeven:

> Hi Stefan,
>
> On Wed, Sep 5, 2018 at 8:11 AM Stefan Niestegge <[hidden email]> wrote:
>> Am 05.09.2018 um 03:01 schrieb Michael Schmitz:
>>> There's no right Alt keycode in the map. Does the default keymap work on
>>> the text console? I.e., do you get correct behaviour for Alt and
>>> CapsLock there?
>>
>> Yes, i can switch VT from one to other, but not back from X11,
>> for example. CapsLock also working as desired.
>
> Can you switch back from X11 using e.g. CTRL + ALT + F1
> (CTRL is the key)?

No, since i have no working Alt key on X11 its like pressing CTRL+F1.

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Michael Schmitz-4
In reply to this post by Stefan Niestegge-2
Stefan,

Am 05.09.2018 um 18:08 schrieb Stefan Niestegge:
>
>
> Am 05.09.2018 um 03:01 schrieb Michael Schmitz:
>> Stefan,
>>
>> good to hear you got the TT to boot - what did you change in the boot
>> options BTW?
>
> No no, this is happening on my Falcon.

OK, that means I should be able to reproduce this easily.

>>
>>
>> On 05/09/18 09:20, Stefan Niestegge wrote:
>>> Hello,
>>>
>>> on my Falcon i have the problem that under heavy load (like apt
>>> update) moving the mouse often causes a key "hang" and repeat. Pressing
>>> the space bar stops the repeating of the hanging key.
>>
>> Keyboard interrupts can be locked out for long enough for the driver
>> to miss data. Apparently that does include crucial break codes.
>>
>> Do you see any 'keyboard overrun' messages in the console logs?
>
> no, i just see whereever the cursor is, one character, repeating until i
> hit space bar. can be on X11 or on the console.

Odd, I don't see that. But perhaps I should try with some IO load.

>>> On an Atari, the mouse is connected to the keyboard, and produces
>>> keyboard-like events. Moving a mousewheel is same as cursor up/down,
>>> for example. I guess that the buffer overflows when CPU is occupied.
>>>
>>> If someone has an idea how to prevent that, i'd be thankful.
>>> But then, its not a showstopping issue. A 100& used CPU will probably
>>> just fail to fetch the IKBD buffer in time.
>>
>> The keyboard driver already tries to resynchronize the packet stream
>> if it missed packets. Maybe we also need to synthesize a break code if
>> the last key event sent to the input layer was a make code. Look at
>> the state machine in arch/m68k/atari/atakeyb.c - line 163 says to skip
>> this byte which is certainly necessary, but maybe additionally you
>> want to check whether the previous keyboard state was KEYBOARD, and
>> the break_flag was clear, and send out an input event for the previous
>> scancode as key up event in that case . Need to keep track of the
>> previous scancode though, and it won't protect you from key repeats
>> when multiple keys were recorded as down at the time the overrun happens.
>
> You're assuming i understand code, which is not the case.

I'll try to come up with something you could try.

>
>>
>>>
>>>
>>> The more serious problem i have is probably just a configuring issue.
>>>
>>> Using dpk-reconfigure keyboard-configuration i can choose Atari TT
>>> keyboard with my DE layout, which does pretty well.
>>>
>>> In older X11 (XFree86) documentation, there is "ataritt" layout for X11.
>>> The Debian sid we now work on does not know that layout and defaults to
>>> PC105 even when my xorg.conf clearly defines ataritt.
>>
>> The old layout probably used the old Atari scancodes and would be
>> useless now. The Atari keyboard driver uses a hardcoded key map as
>> found in drivers/input/keyboard/atakbd.c (US layout) translating the
>> Atari scancodes to Linux keycodes which I worked out from some docs
>> found on the web, and logging raw scancodes on my Falcon. There are
>> quite a few scancodes that I wasn't sure about (see FIXME comments in
>> same), patches are welcome.
>>
> So the fix lies in finishing atakbd.c? Xorg will still default to PC105,
> won't it?

The current kernel keymap definitely needs some work, I've found quite a
few keys around the keypad that generate wrong keycodes. Unfortunately,
'showkey' is not much help there as many keycodes are duplicates. I'll
have to make a fresh start on this.
There are old keymaps in the console-data package which should be useful
to work out possible mappings if you take into account the current
kernel keymap, but I've found some discrepancies between these and the
kernel keymap, not sure how useful these will be.

It might be possible to use the right shift key as right alt key by
changing the kernel key map, but I'm pretty sure that can be remapped
for X11 by modifying one of the PC keymaps (the keycodes used by the
input layer are PC keycodes, essentially). That would be my preferred
solution.

There should even be a way to remap keys within the input device layer
(using a virtual keyboad device as source for X11 keycodes), but I
haven't had a look at input device drivers in about a decade now.

>
>>>
>>> The tool xev shows that cursor keys produce same keycodes as found
>>> with numpad keys. I have not completely understood how that works,
>>> or there is a more serious issue here.
>>
>> That may be a result of the PC105 key map - key codes for cursor keys
>> and keypad keys are distinct in the Atari key map.
>
> Geerts idea of numlock off explains it well.

Need to remap NumLock as well, then.

>>
>>>
>>> With modifying my xmodmap i was able to get cursor keys, | and ~
>>> working, but not the Alternate key. Without Alt, entering @ and many
>>> other important sysmbos is not possible. I also need it to move
>>> windows that have their title bars out of the screen.
>>>
>>> I would also like to have an AltGr instead of the capslock.
>>
>> There's no right Alt keycode in the map. Does the default keymap work
>> on the text console? I.e., do you get correct behaviour for Alt and
>> CapsLock there?
>
> Yes, i can switch VT from one to other, but not back from X11,
> for example. CapsLock also working as desired.

Odd, I found that CapsLock had to be held down in order to shift. Once
released, the keyboard reverted to lower case. The fix for that may be
easy enough, I'll take a look.

>>
>> Maybe the TT needs a different default keymap. Edit the mapping in
>> drivers/input/keyboard/atakbd.c until you have something that works on
>> your TT keyboard (on the text console, mind you!) and submit that to
>> linux-m68k please.
>>
> I am very confident that TT and Falcon do not differ here.
>
>> To see the raw scancodes, add  a dprintk statement before line 198 in
>> drivers/input/keyboard/atakbd.c (make sure you can log in remotely to
>> change the console loglevel to enable/disable printing these messages!).
>
> I can login via ssh, but i cannot compile the same kernel as provided
> during install yet. Carsten will come over today, maybe we get it
> running on the crosscompiler.

Yep, don't native compile kernels please. Unless you want to stress test
your Falcon. And the install kernels may have additional patches not
found in mainline. Adrian may be able to advise on install kernel builds.

I find it much easier to build my own kernels, but that's just my
personal preference :-)

Cheers,

        Michael

>
> Greetings,
> Stefan
>
>>
>> Cheers,
>>
>>      Michael
>>
>>>
>>>
>>> Maybe someone here has some insight, or a good read for me.
>>>
>>>
>>> Greetings, and thanks for reading,
>>> Stefan
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

David Gálvez
In reply to this post by Michael Schmitz-4
Hi Michael,

2018-09-05 3:01 GMT+02:00 Michael Schmitz <[hidden email]>:

>> on my Falcon i have the problem that under heavy load (like apt update)
>> moving the mouse often causes a key "hang" and repeat. Pressing
>> the space bar stops the repeating of the hanging key.
>
>
> Keyboard interrupts can be locked out for long enough for the driver to miss
> data. Apparently that does include crucial break codes.
>
> Do you see any 'keyboard overrun' messages in the console logs?
>
>> On an Atari, the mouse is connected to the keyboard, and produces
>> keyboard-like events. Moving a mousewheel is same as cursor up/down,
>> for example. I guess that the buffer overflows when CPU is occupied.
>>
>> If someone has an idea how to prevent that, i'd be thankful.
>> But then, its not a showstopping issue. A 100& used CPU will probably
>> just fail to fetch the IKBD buffer in time.
>
>
> The keyboard driver already tries to resynchronize the packet stream if it
> missed packets. Maybe we also need to synthesize a break code if the last
> key event sent to the input layer was a make code. Look at the state machine
> in arch/m68k/atari/atakeyb.c - line 163 says to skip this byte which is
> certainly necessary, but maybe additionally you want to check whether the
> previous keyboard state was KEYBOARD, and the break_flag was clear, and send
> out an input event for the previous scancode as key up event in that case .
> Need to keep track of the previous scancode though, and it won't protect you
> from key repeats when multiple keys were recorded as down at the time the
> overrun happens.
>

I tried to fix this key stuck effect in FreeMiNT's keyboard driver but
I failed :-/, in this link you have some information about my attempt:

https://github.com/freemint/freemint/issues/87

I'm a bit sceptic that this can be fixed in the keyboard driver, but
may be I'm wrong and I missed something. What it could be done is a
workaround in the drivers that are disabling the interrupts for a long
time, this workaround is a clever solution done in the drivers for the
Lightning VME an USB card for the TT, MiNT's NetUSBee driver copied
that workaround. It's all in the link above.

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Andreas Schwab-2
In reply to this post by Michael Schmitz-4
On Sep 05 2018, Michael Schmitz <[hidden email]> wrote:

> The old layout probably used the old Atari scancodes and would be useless
> now. The Atari keyboard driver uses a hardcoded key map as found in
> drivers/input/keyboard/atakbd.c (US layout) translating the Atari
> scancodes to Linux keycodes which I worked out from some docs found on the
> web, and logging raw scancodes on my Falcon. There are quite a few
> scancodes that I wasn't sure about (see FIXME comments in same), patches
> are welcome.

Please try this:

diff --git a/drivers/input/keyboard/atakbd.c b/drivers/input/keyboard/atakbd.c
index 6f62da2909..1321e87574 100644
--- a/drivers/input/keyboard/atakbd.c
+++ b/drivers/input/keyboard/atakbd.c
@@ -76,7 +76,6 @@ MODULE_LICENSE("GPL");
 
 
 static unsigned char atakbd_keycode[0x72] = { /* American layout */
- [0] = KEY_GRAVE,
  [1] = KEY_ESC,
  [2] = KEY_1,
  [3] = KEY_2,
@@ -117,9 +116,9 @@ static unsigned char atakbd_keycode[0x72] = { /* American layout */
  [38] = KEY_L,
  [39] = KEY_SEMICOLON,
  [40] = KEY_APOSTROPHE,
- [41] = KEY_BACKSLASH, /* FIXME, '#' */
+ [41] = KEY_GRAVE,
  [42] = KEY_LEFTSHIFT,
- [43] = KEY_GRAVE, /* FIXME: '~' */
+ [43] = KEY_BACKSLASH,
  [44] = KEY_Z,
  [45] = KEY_X,
  [46] = KEY_C,
@@ -145,45 +144,34 @@ static unsigned char atakbd_keycode[0x72] = { /* American layout */
  [66] = KEY_F8,
  [67] = KEY_F9,
  [68] = KEY_F10,
- [69] = KEY_ESC,
- [70] = KEY_DELETE,
- [71] = KEY_KP7,
- [72] = KEY_KP8,
- [73] = KEY_KP9,
+ [71] = KEY_HOME,
+ [72] = KEY_UP,
  [74] = KEY_KPMINUS,
- [75] = KEY_KP4,
- [76] = KEY_KP5,
- [77] = KEY_KP6,
+ [75] = KEY_LEFT,
+ [77] = KEY_RIGHT,
  [78] = KEY_KPPLUS,
- [79] = KEY_KP1,
- [80] = KEY_KP2,
- [81] = KEY_KP3,
- [82] = KEY_KP0,
- [83] = KEY_KPDOT,
- [90] = KEY_KPLEFTPAREN,
- [91] = KEY_KPRIGHTPAREN,
- [92] = KEY_KPASTERISK, /* FIXME */
- [93] = KEY_KPASTERISK,
- [94] = KEY_KPPLUS,
- [95] = KEY_HELP,
+ [80] = KEY_DOWN,
+ [82] = KEY_INSERT,
+ [83] = KEY_DELETE,
  [96] = KEY_102ND,
- [97] = KEY_KPASTERISK, /* FIXME */
- [98] = KEY_KPSLASH,
+ [97] = KEY_UNDO,
+ [98] = KEY_HELP,
  [99] = KEY_KPLEFTPAREN,
  [100] = KEY_KPRIGHTPAREN,
  [101] = KEY_KPSLASH,
  [102] = KEY_KPASTERISK,
- [103] = KEY_UP,
- [104] = KEY_KPASTERISK, /* FIXME */
- [105] = KEY_LEFT,
- [106] = KEY_RIGHT,
- [107] = KEY_KPASTERISK, /* FIXME */
- [108] = KEY_DOWN,
- [109] = KEY_KPASTERISK, /* FIXME */
- [110] = KEY_KPASTERISK, /* FIXME */
- [111] = KEY_KPASTERISK, /* FIXME */
- [112] = KEY_KPASTERISK, /* FIXME */
- [113] = KEY_KPASTERISK /* FIXME */
+ [103] = KEY_KP7,
+ [104] = KEY_KP8,
+ [105] = KEY_KP9,
+ [106] = KEY_KP4,
+ [107] = KEY_KP5,
+ [108] = KEY_KP6,
+ [109] = KEY_KP1,
+ [110] = KEY_KP2,
+ [111] = KEY_KP3,
+ [112] = KEY_KP0,
+ [113] = KEY_KPDOT,
+ [114] = KEY_KPENTER,
 };
 
 static struct input_dev *atakbd_dev;

Andreas.

--
Andreas Schwab, [hidden email]
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Michael Schmitz-4
Hi Andreas,

thanks, will try that.

Cheers,

  Michael

On Thu, Sep 6, 2018 at 4:16 AM Andreas Schwab <[hidden email]> wrote:

>
> On Sep 05 2018, Michael Schmitz <[hidden email]> wrote:
>
> > The old layout probably used the old Atari scancodes and would be useless
> > now. The Atari keyboard driver uses a hardcoded key map as found in
> > drivers/input/keyboard/atakbd.c (US layout) translating the Atari
> > scancodes to Linux keycodes which I worked out from some docs found on the
> > web, and logging raw scancodes on my Falcon. There are quite a few
> > scancodes that I wasn't sure about (see FIXME comments in same), patches
> > are welcome.
>
> Please try this:
>
> diff --git a/drivers/input/keyboard/atakbd.c b/drivers/input/keyboard/atakbd.c
> index 6f62da2909..1321e87574 100644
> --- a/drivers/input/keyboard/atakbd.c
> +++ b/drivers/input/keyboard/atakbd.c
> @@ -76,7 +76,6 @@ MODULE_LICENSE("GPL");
>
>
>  static unsigned char atakbd_keycode[0x72] = {  /* American layout */
> -       [0]      = KEY_GRAVE,
>         [1]      = KEY_ESC,
>         [2]      = KEY_1,
>         [3]      = KEY_2,
> @@ -117,9 +116,9 @@ static unsigned char atakbd_keycode[0x72] = {       /* American layout */
>         [38]     = KEY_L,
>         [39]     = KEY_SEMICOLON,
>         [40]     = KEY_APOSTROPHE,
> -       [41]     = KEY_BACKSLASH,       /* FIXME, '#' */
> +       [41]     = KEY_GRAVE,
>         [42]     = KEY_LEFTSHIFT,
> -       [43]     = KEY_GRAVE,           /* FIXME: '~' */
> +       [43]     = KEY_BACKSLASH,
>         [44]     = KEY_Z,
>         [45]     = KEY_X,
>         [46]     = KEY_C,
> @@ -145,45 +144,34 @@ static unsigned char atakbd_keycode[0x72] = {     /* American layout */
>         [66]     = KEY_F8,
>         [67]     = KEY_F9,
>         [68]     = KEY_F10,
> -       [69]     = KEY_ESC,
> -       [70]     = KEY_DELETE,
> -       [71]     = KEY_KP7,
> -       [72]     = KEY_KP8,
> -       [73]     = KEY_KP9,
> +       [71]     = KEY_HOME,
> +       [72]     = KEY_UP,
>         [74]     = KEY_KPMINUS,
> -       [75]     = KEY_KP4,
> -       [76]     = KEY_KP5,
> -       [77]     = KEY_KP6,
> +       [75]     = KEY_LEFT,
> +       [77]     = KEY_RIGHT,
>         [78]     = KEY_KPPLUS,
> -       [79]     = KEY_KP1,
> -       [80]     = KEY_KP2,
> -       [81]     = KEY_KP3,
> -       [82]     = KEY_KP0,
> -       [83]     = KEY_KPDOT,
> -       [90]     = KEY_KPLEFTPAREN,
> -       [91]     = KEY_KPRIGHTPAREN,
> -       [92]     = KEY_KPASTERISK,      /* FIXME */
> -       [93]     = KEY_KPASTERISK,
> -       [94]     = KEY_KPPLUS,
> -       [95]     = KEY_HELP,
> +       [80]     = KEY_DOWN,
> +       [82]     = KEY_INSERT,
> +       [83]     = KEY_DELETE,
>         [96]     = KEY_102ND,
> -       [97]     = KEY_KPASTERISK,      /* FIXME */
> -       [98]     = KEY_KPSLASH,
> +       [97]     = KEY_UNDO,
> +       [98]     = KEY_HELP,
>         [99]     = KEY_KPLEFTPAREN,
>         [100]    = KEY_KPRIGHTPAREN,
>         [101]    = KEY_KPSLASH,
>         [102]    = KEY_KPASTERISK,
> -       [103]    = KEY_UP,
> -       [104]    = KEY_KPASTERISK,      /* FIXME */
> -       [105]    = KEY_LEFT,
> -       [106]    = KEY_RIGHT,
> -       [107]    = KEY_KPASTERISK,      /* FIXME */
> -       [108]    = KEY_DOWN,
> -       [109]    = KEY_KPASTERISK,      /* FIXME */
> -       [110]    = KEY_KPASTERISK,      /* FIXME */
> -       [111]    = KEY_KPASTERISK,      /* FIXME */
> -       [112]    = KEY_KPASTERISK,      /* FIXME */
> -       [113]    = KEY_KPASTERISK       /* FIXME */
> +       [103]    = KEY_KP7,
> +       [104]    = KEY_KP8,
> +       [105]    = KEY_KP9,
> +       [106]    = KEY_KP4,
> +       [107]    = KEY_KP5,
> +       [108]    = KEY_KP6,
> +       [109]    = KEY_KP1,
> +       [110]    = KEY_KP2,
> +       [111]    = KEY_KP3,
> +       [112]    = KEY_KP0,
> +       [113]    = KEY_KPDOT,
> +       [114]    = KEY_KPENTER,
>  };
>
>  static struct input_dev *atakbd_dev;
>
> Andreas.
>
> --
> Andreas Schwab, [hidden email]
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Michael Schmitz-4
In reply to this post by Andreas Schwab-2
Hi Andreas,

thanks, this works (with one minor correction - keymap array size and
unhandled scancode limit bumped up by one). I'll submit my version to
linux-m68k, along with the CapsLock fix.

Geert - can this go through your tree, or via the input maintainers?

Cheers,

        Michael


Am 06.09.2018 um 04:16 schrieb Andreas Schwab:

> On Sep 05 2018, Michael Schmitz <[hidden email]> wrote:
>
>> The old layout probably used the old Atari scancodes and would be useless
>> now. The Atari keyboard driver uses a hardcoded key map as found in
>> drivers/input/keyboard/atakbd.c (US layout) translating the Atari
>> scancodes to Linux keycodes which I worked out from some docs found on the
>> web, and logging raw scancodes on my Falcon. There are quite a few
>> scancodes that I wasn't sure about (see FIXME comments in same), patches
>> are welcome.
>
> Please try this:
>
> diff --git a/drivers/input/keyboard/atakbd.c b/drivers/input/keyboard/atakbd.c
> index 6f62da2909..1321e87574 100644
> --- a/drivers/input/keyboard/atakbd.c
> +++ b/drivers/input/keyboard/atakbd.c
> @@ -76,7 +76,6 @@ MODULE_LICENSE("GPL");
>
>
>  static unsigned char atakbd_keycode[0x72] = { /* American layout */
> - [0] = KEY_GRAVE,
>   [1] = KEY_ESC,
>   [2] = KEY_1,
>   [3] = KEY_2,
> @@ -117,9 +116,9 @@ static unsigned char atakbd_keycode[0x72] = { /* American layout */
>   [38] = KEY_L,
>   [39] = KEY_SEMICOLON,
>   [40] = KEY_APOSTROPHE,
> - [41] = KEY_BACKSLASH, /* FIXME, '#' */
> + [41] = KEY_GRAVE,
>   [42] = KEY_LEFTSHIFT,
> - [43] = KEY_GRAVE, /* FIXME: '~' */
> + [43] = KEY_BACKSLASH,
>   [44] = KEY_Z,
>   [45] = KEY_X,
>   [46] = KEY_C,
> @@ -145,45 +144,34 @@ static unsigned char atakbd_keycode[0x72] = { /* American layout */
>   [66] = KEY_F8,
>   [67] = KEY_F9,
>   [68] = KEY_F10,
> - [69] = KEY_ESC,
> - [70] = KEY_DELETE,
> - [71] = KEY_KP7,
> - [72] = KEY_KP8,
> - [73] = KEY_KP9,
> + [71] = KEY_HOME,
> + [72] = KEY_UP,
>   [74] = KEY_KPMINUS,
> - [75] = KEY_KP4,
> - [76] = KEY_KP5,
> - [77] = KEY_KP6,
> + [75] = KEY_LEFT,
> + [77] = KEY_RIGHT,
>   [78] = KEY_KPPLUS,
> - [79] = KEY_KP1,
> - [80] = KEY_KP2,
> - [81] = KEY_KP3,
> - [82] = KEY_KP0,
> - [83] = KEY_KPDOT,
> - [90] = KEY_KPLEFTPAREN,
> - [91] = KEY_KPRIGHTPAREN,
> - [92] = KEY_KPASTERISK, /* FIXME */
> - [93] = KEY_KPASTERISK,
> - [94] = KEY_KPPLUS,
> - [95] = KEY_HELP,
> + [80] = KEY_DOWN,
> + [82] = KEY_INSERT,
> + [83] = KEY_DELETE,
>   [96] = KEY_102ND,
> - [97] = KEY_KPASTERISK, /* FIXME */
> - [98] = KEY_KPSLASH,
> + [97] = KEY_UNDO,
> + [98] = KEY_HELP,
>   [99] = KEY_KPLEFTPAREN,
>   [100] = KEY_KPRIGHTPAREN,
>   [101] = KEY_KPSLASH,
>   [102] = KEY_KPASTERISK,
> - [103] = KEY_UP,
> - [104] = KEY_KPASTERISK, /* FIXME */
> - [105] = KEY_LEFT,
> - [106] = KEY_RIGHT,
> - [107] = KEY_KPASTERISK, /* FIXME */
> - [108] = KEY_DOWN,
> - [109] = KEY_KPASTERISK, /* FIXME */
> - [110] = KEY_KPASTERISK, /* FIXME */
> - [111] = KEY_KPASTERISK, /* FIXME */
> - [112] = KEY_KPASTERISK, /* FIXME */
> - [113] = KEY_KPASTERISK /* FIXME */
> + [103] = KEY_KP7,
> + [104] = KEY_KP8,
> + [105] = KEY_KP9,
> + [106] = KEY_KP4,
> + [107] = KEY_KP5,
> + [108] = KEY_KP6,
> + [109] = KEY_KP1,
> + [110] = KEY_KP2,
> + [111] = KEY_KP3,
> + [112] = KEY_KP0,
> + [113] = KEY_KPDOT,
> + [114] = KEY_KPENTER,
>  };
>
>  static struct input_dev *atakbd_dev;
>
> Andreas.
>

Reply | Threaded
Open this post in threaded view
|

Re: keyboard issues

Geert Uytterhoeven
Hi Michael,

On Thu, Sep 6, 2018 at 10:35 AM Michael Schmitz <[hidden email]> wrote:
> thanks, this works (with one minor correction - keymap array size and
> unhandled scancode limit bumped up by one). I'll submit my version to
> linux-m68k, along with the CapsLock fix.
>
> Geert - can this go through your tree, or via the input maintainers?

Via the input maintainers.

> Am 06.09.2018 um 04:16 schrieb Andreas Schwab:
> > On Sep 05 2018, Michael Schmitz <[hidden email]> wrote:
> >
> >> The old layout probably used the old Atari scancodes and would be useless
> >> now. The Atari keyboard driver uses a hardcoded key map as found in
> >> drivers/input/keyboard/atakbd.c (US layout) translating the Atari
> >> scancodes to Linux keycodes which I worked out from some docs found on the
> >> web, and logging raw scancodes on my Falcon. There are quite a few
> >> scancodes that I wasn't sure about (see FIXME comments in same), patches
> >> are welcome.
> >
> > Please try this:

Gr{oetje,eeting}s,

                        Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [hidden email]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds