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