Re: keyboard issues
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 to: