#856 Keyboard not working (xpet / xaw / linux)

[Andre Fachat]

Compiled VICE with
./configure
make
make install

started xpet

and the keyboard is NOT working.

In the startup log I get:

Keyboard: Loading keymap /usr/local/lib64/vice/PET/x11_sym.vkm'. '!yboard: Error - Could not find key
'-><empty/null>'.ading keymapx11_buuk_sym.vkm

[Andre Fachat]

BTW: "-symkeymap" does not seem to have any effect. I tried to load various other keymap files, but xpet always tries to load x11_sym.vkm instead!

[Andre Fachat]

"-keymap" does not show any effect

[gpz]

mmmh i wonder how you managed to get a scrambled error message like this..... i cant reproduce this no matter what i do

did you remove the old config file from previous install?

[compyx]

The garbled messages look exactly like my SDL build on Raspberry framebuffer. (bug #836).

Edit: So to get the proper log output, you may have to redirect stdout/stderr to a file.

[Andre Fachat]

I did not remove anything, as this is a NEW install on a NEW ubuntu 16.04 64bit installation. No VICE before. Maybe you could try that in a VM.

[Andre Fachat]

set | grep LC_*
LC_ADDRESS=de_DE.UTF-8
LC_IDENTIFICATION=de_DE.UTF-8
LC_MEASUREMENT=de_DE.UTF-8
LC_MONETARY=de_DE.UTF-8
LC_NAME=de_DE.UTF-8
LC_NUMERIC=de_DE.UTF-8
LC_PAPER=de_DE.UTF-8
LC_TELEPHONE=de_DE.UTF-8
LC_TIME=de_DE.UTF-8

echo $LANG
en_US.UTF-8

(I use en_US lang, but LC in German, as I love my correct date/numeric format etc, but don't need (possibly bad) translated UIs)

[Andre Fachat]

Oh now. I think I know the answer. Tells me noone tested this on Non-Windows machines...
Looking at the logs from "xpet > xpet.log" I see this:

Keyboard: Loading keymap /usr/local/lib64/vice/PET/x11_sym.vkm'. Keyboard: Error - Could not find key^M'!
Keyboard: Error loading keymap x11_buuk_sym.vkm^M'-><empty null="">'.</empty>

Are the keysym files in Windows format? I.e. only with ^M instead of/withou a proper LF?

(thanks to compyx for the hint with the output redirection)

[gpz]

actually VICE is almost exclusively tested on linux :) i dont get this message here for that matter shrug

[Andre Fachat]

Ok, I take back the last comment, there are proper "0d 0a" in the hexdump. Maybe you can better understand that log message.

[Andre Fachat]

Anyway, the cmdline parameters as mentioned above don't seem to have any effect in the selection of the keymap file, which should also be investigated.

[Andre Fachat]

@gpz: I don't know, but did you test on a clean install? I.e. an "unpolluted" --prefix? I remember having xpet keymap problems in an earlier version and may have fixed it in /usr/local/lib/vice then, so new installs would work. Maybe there is still something like this lurking around?

[compyx]

I compiled and installed the Xaw version of VICE into a new prefix, /opt/games. All the files required are there and the palette and keymap files are loaded from /opt/games/lib64/vice. So far so good.

However when try to switch to 'positional', the x11_buuk_sym.vkm file gets loaded. And when switching the language to German, the following happens:

Keyboard: Loading keymap `/opt/games/lib64/vice/PET/x11_bude_sym.vkm'.
Keyboard:  including keymap `/opt/games/lib64/vice/PET/x11_buuk_sym.vkm'.
Keyboard: Error - Bad row/column value (-1/9) for keysym `KP_9'.
Keyboard: Error - Bad row/column value (-2/9) for keysym `r'.

Looking at the actual x11_bude_*.vmk files, all they contain is an include of "x11_buuk_pos.vkm and a nice comment block of how the German keymap differs from the UK one, but no actual key settings.

So all those keymap files are basically the same: x11_buuk_sym.vkm. There's not actual useful data in them.

Edit: I can't reproduce the load errors though.

[gpz]

those errors are normal (and have always been there)

[compyx]

could we at least at a "don't worry about it" to the message? :)

[gpz]

obviously the real fix would be to fix the damn keymaps =)

[compyx]

That would mean at least adding a positional keymap, and work from there. Problem is the PET keyboard doesn't exactly map nicely to a standard PC keyboard. But I suppose mapping as many keys as possible positional and then using whatever is left on the PC keyboard for the 'lesser-used' PET keys will do (ie using insert.del,home,pgdown etc).

[Andre Fachat]

In this case, please make sure international PET keyboards are supported - some of them Do have a) other positions and b) other special keys IIRC.

[compyx]

Are you using the 3.0 tarball or SVN? I see I fixed some code in the keymap parsing (it now handles different EOL-styles, no matter what OS is used), two days after the source tarball was generated. The commit is r32528

So perhaps use that as a patch and see if that solves things.

[Greg King]

Andre, only the WinVICE packages should have "0x0d 0x0a" line terminators in their text files. Your files should have only line-feeds in them (no carriage-returns).

[Andre Fachat]

I am using the 3.0 source tarball.

Well. In fact my files DO have "0x0d 0x0a" as line terminators in them. And in fact this is the problem - not necessarily for most key definitions, but for the INCLUDE at least (and empty lines it seems). A

tr -d '\r' < x11_sym.vkm.orig | sudo tee x11_sym.vkm

on the main vkm file fixes the problem, the keymap is loaded, keys work - but VICE still complains about not finding a key "^M" in the loaded file. (Didn't check all keys though).

[compyx]

Weird, keymaps should install with their 'native' EOL style. Do you have dos2unix installed? VICE uses that, but doesn't complain if it's missing for some reason.

[Andre Fachat]

For the INCLUDE it seems that the filename parsing is rather simple. In keyboard_keyword_include() the filename is simply derived by tokenizing the input line using space and tab as separators. A carriage return (^M) would thus be included as last character in the filename, preventing the emulator to load the included file.

The same technique is used in keyboard_parse_entry(), where

key = strtok(buffer, " \t:");

so a carriage return is also included in the key name.
But this only happens on an empty line when the carriage return is not filtered, it is the only character in the line - so the line is "not empty" and a parse_entry() is attempted, otherwise it would have been ignored.

But why is the carriage return not filtered? The file is opened via sysfile_open(... , MODE_READ_TEXT) and then read via fgets.
There even is a "remove newline" feature...:

buffer[strlen(buffer) - 1] = 0; /* remove newline */

but this only removes the newline (0x0a) of the "0x0d 0x0a" end-of-line sequence.

So: either in the build/install procedure, remove the 0x0d on Unix-ish systems, or remove the "newline" like this:

while ((c = buffer[strlen(buffer) - 1]) == 0x0a || c == 0x0d)
    buffer[strlen(buffer) - 1] = 0;

Regards,
André

[Andre Fachat]

I now see your patch r32528 already seems to exactly do what I suggested :-)

[Andre Fachat]

No, I don't have "dos2unix" installed.

[compyx]

My patch did that, removing any trailing whitespace (including 0x0d) from the line read from a keymap. That, at least on my box, seemed to allow the keymap 'parsing' with strtok to work.