openMSX
Control-key in combination with letter key always maps to US English mapping, instead of respecting the keyboard layout (e.g. Russian JCUKEN)
Hello,
I have the following problem:
If I use the BASIC program
10 A$=INKEY$
20 IF A$="" THEN 10
30 PRINT ASC(A$)
40 GOTO 10
it prints, for example, 65 for the key A (as it should) but control keys mapping seems to be very broken:
CTRL-A gives 6 CTRL-B gives 9 CTRL-C gives 19 ...
On, for example, fMSX I get expected 1, 2, 3, ...
This breaks things like keyboard presses in text editors, such as TOR, WordStar, built-in editor in Turbo Pascal...
I run Yamaha YIS-805-128R2 in OpenMSX 19.1.0 on Windows 11, but changing the machine or running OpenMSX on FreeBSD does not change anything.
By the way, if I set kbd_mode to POSITIONAL, Ctrl-A gives 1, etc. However, it is unacceptable, as Yamaha YIS-805 had a bizarre keyboard layout (English keys were in places, corresponding to the places of similar characters in the Russian layout; for example, A is at the place where QWERTY F is).
If you run an MSX program that shows the keyboard matrix, does it show the correct bits?
Is there a place where I can get this program? I am, unfortunately, not sure what you are speaking about (but I understand what "keyboard matrix" is).
So, you get the issue only with the CHARACTER mode? What kind of host PC keyboard do you use?
Yes, it happens only with CHARACTER. I'm using United States-DVORAK keyboard; changing this to QWERTY does not help. I'll double-check now.
Clickety-click
Yes, I have installed English (US) language (my usual one is English (Finland)) and US QWERTY keyboard, with the same result.
Since you are asking about my host keyboard, can you confirm that you have tried the program on your computer and it works properly?
I also use the CHARACTER mode and indeed, I just get 1, 2, 3 for CTRL-A, B, C. But that is on a Philips NMS 8245. On that Russian Yamaha configuration, I indeed get different output.
I am now using the latest development version, which has a new keyboard visualizer (only based on a standard US English MSX keyboard layout though, but that doesn't matter here).
This is when I type a:
(so that maps the the position where the F is on a US English keyboard).
But when I type CTRL-A, it maps to the US English A key:
(I had to make a screenshot of a screencapture to properly show this....)
When I type SHIFT-A, it maps to the proper combination again:
Maybe a bug in the CHARACTER mode when combining with the CTRL modifier? If this is true, things should work fine for you on a MSX machine with a US ENglish like layout. Can you confirm?
The Russian keyboard mapping seems consistent:
00001, 33, CTRL # ^A
00041, 33, SHIFT # A (LATIN CAPITAL LETTER A)
00061, 33, # a (LATIN SMALL LETTER A)
Hmm. I think I have tried with different machines without success, but I'll try again.
Obviously, I did something wrong earlier. I have tried on Panasonic F1-GT, which I think I tried on before, but it works.
I think you are correct. In JCUKEN there are I and S on places of B and C in QWERTY, hence 9 and 19 with Ctrl.
@m9710797 I debugged the code a bit, but the problem is that we get into a path that is without unicode:
Key pressed, unicode: 0x0000, keyCode: 0x400000e0, keyName: Left Ctrl
Not a normal key, but a spcial key or something
processSdlKey, look up in keyCodeTab
PressKeymatrixEvent row , mask:
Key pressed, unicode: 0x0000, keyCode: 0x00061, keyName: A+CTRL
Not a normal key, but a spcial key or something
processSdlKey, look up in keyCodeTab
PressKeymatrixEvent row , mask: @
So this goes to the hardcoded US English like table instead of using the mapping.
Another tests: I added logging in InputEventGenerator::poll() and from that it is clear that for CTRL-A, no SDL_TEXTINPUT event is produced by SDL, and because of that, no unicode interpretation is done.
Probably related experiments with Right Alt (according to the documentation it is KANA key, which on Yamaha YIS-805-128R2R2 is РУС, meaning switching to the Russian layout):
- it does not lock.
- Ralt+Key works incorrectly. If I keep pressing Ralt-a, sometimes (!) I'm getting in "фfфfфf", and sometimes "ffffff", etc. Russian "ф" is, basically, "f", and it is indeed located (in qwerty, or even dvorak) where Latin "a" is (but not in Yamaha YIS-805-128R2R2; it should be Russian "а" there); what "f" is doing there is a big question.
I also think (but I'm not sure yet) that Graph works incorrectly too.
Things I've noticed in POSITIONAL mode:
- KANA locks
- I'm getting QWERTY layout, not JCUKENG
Ok, now I know when I get "ф" and when I get "f": every release of RAlt switches between "ф" and "f", so if I repeatedly press Ralt-A, releasing both keys, I'm getting "фfфfфf". If I keep RAlt pressed, repeated pressing of Ralt-A repeats the first character, be it "ф" or "f".
Probably related experiments with Right Alt (according to the documentation it is KANA key, which on Yamaha YIS-805-128R2R2 is РУС, meaning switching to the Russian layout):
* it does not lock.
Do you mean it doesn't lock in openMSX or on the real machine? I do see it locking in openMSX and the configuration says it must lock. It shows up as the CODE LED being lit.
* Ralt+Key works incorrectly. If I keep pressing Ralt-a, sometimes (!) I'm getting in "фfфfфf", and sometimes "ffffff", etc. Russian "ф" is, basically, "f", and it is indeed located (in qwerty, or even dvorak) where Latin "a" is (but not in Yamaha YIS-805-128R2R2; it should be Russian "а" there); what "f" is doing there is a big question.
It changes because if you keep it pressed, you toggle the lock state.
I also think (but I'm not sure yet) that Graph works incorrectly too.
Please elaborate.
Things I've noticed in POSITIONAL mode:
* KANA locks * I'm getting QWERTY layout, not JCUKENG
If I set the mode to POSITIONAL with the Yamaha YIS-805/128R2 and touch the QWERTY keys in that order on my US English keyboard, I see jcuken appearing int he MSX. Is that not true for you?
* it does not lock.Do you mean it doesn't lock in openMSX or on the real machine? I do see it locking in openMSX and the configuration says it must lock. It shows up as the CODE LED being lit.
It does not lock in openMSX with my configuration.
Things I've noticed in POSITIONAL mode:
* KANA locks * I'm getting QWERTY layout, not JCUKENGIf I set the mode to POSITIONAL with the Yamaha YIS-805/128R2 and touch the QWERTY keys in that order on my US English keyboard, I see
jcukenappearing int he MSX. Is that not true for you?
I've just in case rebooted a computer, and now in POSITIONAL mode keyboard is correct. KANA still locks. Still, in CHARACTER mode KANA does not lock (and even if it will, how am I getting "f" from RAlt-a?)
Do you mean it doesn't lock in openMSX or on the real machine? I do see it locking in openMSX and the configuration says it must lock. It shows up as the CODE LED being lit.
What it shows to me is KANA led, not CODE led. It is indeed lit after I press right Alt and looks locked, but as soon as I press "a" the light goes away (probably gets KANA gets unlocked), and the entered character is Latin "a" not Russian "ф".
My mistake, I meant kana LED indeed. The key locks, but if you use CHARACTER mode and type a character that requires the KANA key to be pressed, it will be unlocked after the press is done. To type the Russian "ф" in character mode, you must type it how you would type it on your PC :) That's the whole point of character mode. But anyway, this is a different issue than the original.
https://github.com/user-attachments/assets/365882ad-d303-40ce-9de5-91c3bbfe4cf2
What happens here:
- I press RAlt (KANA is lit)
- I release RAlt (KANA is still lit)
- I press Latin "a" (I would expect "ф"; instead I am getting Latin "a" and KANA seemingly unlocks).
- I press RAlt+a, "ф" is typed.
- I release both keys.
- I press RAlt+a, "f" is typed. Where it comes from?
My mistake, I meant kana LED indeed. The key locks, but if you use CHARACTER mode and type a character that requires the KANA key to be pressed, it will be unlocked after the press is done. To type the Russian "ф" in character mode, you must type it how you would type it on your PC :) That's the whole point of character mode. But anyway, this is a different issue than the original.
- Indeed, if I enter "ф" on the host, it goes through to the emulator fine.
- It seems that KANA is unlocked before the press, not after.
- All that does not explain where "f" comes from. That's why I suspected the problem could be related to the original one.
If I press RAlt+a, I do not get the "ф" and I also don't get the "f". I do get another type of a:
The KANA is unlocked, because it would prevent the keyboard from typing a plain "a", which you requested (as you're in character mode).
If I press RAlt+a, I do not get the "ф" and I also don't get the "f". I do get another type of a
This seems to be a Russian "а", which is on the place of Latin "a" in jcukeng layout. Just in case: I'm getting the strange result in CHARACTER mode. I wonder why your results are different. I will try to switch my keyboard layout to qwerty from dvorak (though Russian layout is separate, "a" is one of the two printable characters which stays at the same place, and modifier keys are not affected at all).
My FreeBSD laptop is at my country house; I'll be there on Friday and will try -- FreeBSD machines here are headless.
The KANA is unlocked, because it would prevent the keyboard from typing a plain "a", which you requested (as you're in character mode).
Clear. Thanks for explanation!
I have tried with QWERTY layout, also on another computer, with exactly the same result for RAlt+a: "ф" or "f".