Quote:
Originally Posted by Psicopatico
Humm, I think I get it.
FS_UAE gets its input from codes directly generated by the keyboard and not from the ones translated by the kernel.
Fact is, different keyboards *may* generate different codes, and in fact it is.
I think that's the reason why a kernel translation system exists in the first place.
My keyboards is a Logitech EX 110.
It is a wireless keyboard with multimedia keys and mouse combo, but the receiver is attached to the case via the "usual" two PS2 connectors. In fact it is recognized as a "standard" AT keyboard with an Intel 8042 controller, as the wireless communication is trasparent to the system. (...) So, if FS_UAE uses directly scancodes for a legitimate operational reason, can't we route around the problem by making menu items click-able, in addition to the navigation by keyboard?
At present, mouse-clicking on any area of FS-UAE - menu buttons included - gives the focus to the emulated system.
]My quess is there may soon appear other cases of users with different keyboards brands/model which supply even different codes, so tryng to - say - put up a table of exceptions may quickly become a mess. |
Well, it isn't like keyboard brands/model generally use different scancodes, these are standardized, of course, for instance as "standard 105 key PC keyboard". And you are the first to report the problem, while FS-UAE has been downloaded by users from many countries
To give an example why translated keysyms are not used: Compared to Norwegian and English keyboards German keyboards have Z and Y swapped. That is, the virtual keycodes are swapped when pressing the keys. The physical key Z/English - Y/German has the same scancode. So the Z/Y swap is caused by different keymaps, not different physical keyboards. Anyway, to make the Z/Y keys work correctly for Amiga emulation, the physical Z (English) key is mapped to the corresponding Amiga key.
That is, by pressing Z (English keyboard), this will result in "Z" in workbench if using English workbench keymap, and "Y if using German workbench keymap. Similarly, by pressing Y (German keyboard), this will result in "Z" in workbench if using English workbench keymap, and "Y if using German workbench keymap.
If I simply had used translated key codes ("keysyms") instead, this would not work properly. I do not know of any better / more robust way to solve the key mapping problem without user intervention:
But here are some alternatives (not all are good ideas
):
- use keysyms instead of keycodes and require that everyone switch to (for instance) English keyboard layouts when using FS-UAE (not an alternative).
- use keysyms and require that user configures keyboard layout in the config file (and FS-UAE has information about all different keymaps, and what physical key the key codes correspond to) - alternatively try to get this information automatically from the system in some cases, where it may be possible (would be a nightmare).
- allow the user to create a config file mapping keycodes manually, when the default key mapping does not work properly.
- implement an option to disable keycode mapping, and use translated keysyms as provided by SDL. This would actually work quite well in most cases, and would definitely solve your cursor key problem (but international keys would probably not work correctly in the emulated Amiga).
A combination of the last two points are probably the best way to make FS-UAE more flexible when it comes to keycodes/scancodes.