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