search

MiSTer-devel / ao486_MiSTer

ao486 port for MiSTer
Other
259 stars 68 forks source link

One UK key is not recognised #7

Open Galbi3000 opened 5 years ago

Galbi3000 commented 5 years ago

I just installed this core for the first time today and found that an important key on the UK keyboard is not working! It's the \ key (to the left of Z). Important as that is the backslash for entering paths in DOS!

I have checked, the keyboard works fine on other computers.

It may be a core specific issue or related to the MiSTer in general, I do not know at this point.

thejpster commented 4 years ago

I also see this. My workaround is to leave DOS in US keyboard mode, which means the # key gives you a backslash.

I assume there's some mapping in https://github.com/MiSTer-devel/ao486_MiSTer/blob/master/rtl/soc/ps2/ps2.v which converts from Linux event codes to simulated PS/2 Set 1 scan codes as emitted by an i8042, and this one is just missing? There's a big table in the middle at around line 524 which copies from keyb_recv_buffer to trans, but I can't quite work out the mapping and there aren't any comments explaining what it's converting from/to.

Edit: That table looks like a Scancode Set 1 to Scancode Set 2 conversion (see https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html). I guess trans is fed into a simulation of the i8042, as that chip takes in Set 2 and emits Set 1 for the OS.

Edit 2: That table looks like a Scancode Set 2 to Scancode Set 1 conversion (see https://www.win.tue.nl/~aeb/linux/kbd/scancodes-10.html), which means it is emulating an i8042. Sorry, my Verilog is rusty.

Galbi3000 commented 4 years ago

That workaround is a good idea but far from ideal as it introduces more complications to using the keyboard: symbols in the wrong places!

It's good that you are getting a grip on the code to see where the issue lies, unfortunately my coding days are behind me, I find it hard enough to look at my own code let alone someone else's! 😏

This issue is a major one considering the frequent use of the key in DOS and really needs to be addressed by sorgelig sooner rather than later.

sorgelig commented 4 years ago

MiSTer uses US layout for all cores. It's not an issue. As it's not an issue that German or French layout is not supported. So get a keyboard with international layout - it's not hard to get it today. Or simply re-label the keys. It's not like simple layout switch. One layout is used on Linux then keys sent to FPGA where core expects the US layout to convert it to computer specific layout. Changing layout on Linux means mess the FPGA core which doesn't expect it.

Galbi3000 commented 4 years ago

So many problems with such a short reply! So I will take them one at a time (TL;DR at the end if you just want to skip):

"MiSTer uses US layout for all cores". That's a big mistake that I would expect from rookies! Never hard code regional information. The whole point of regional information is that it changes from region to region. Especially bad to hard code keyboard scan codes when you have no control over the keyboards being used!

"It's not an issue". You can not just say that, the key is a major one for using DOS. Without that key you can not enter full paths required by many commands. That makes it a big issue! If it was a lesser used key then I would accept it as a minor annoyance and would not have even opened the issue in the first place.

"As it's not an issue that German or French layout is not supported". Just because German or French keyboard users have not reported an issue does not make it a non-issue for us UK keyboard users. Their keyboard layouts are not the same as ours and so do not encounter the same issue. The French has \ up beside the 1 key, that's scan code 41 (0x29). The German has it next to 0, scan code 12 (0x0C). That does not mean they do not have issues at all though. Both their keyboards would have issues using « ( » shifted) for French and < ( > shifted) for German because those keys are on the same scan code as the UK \ key, scan code 86 (0x56). Not so much of a problem for the French in general use of DOS but can cause some issues for the Germans when using redirection in DOS.

"So get a keyboard with international layout". An international keyboard is just a regional one with extra markings to show where extra characters are when using the 'Alt Gr' key. The UK international keyboard still has \ in the same place with the same scan code as the normal version of the UK keyboard (a quick search for an example came up with this page: http://zolid.com/uk-intl-kb/index.htm). Maybe do a little research yourself before making such a reply in future!

"Or simply re-label the keys". This is very dismissive of the issue and only serves to make you look lazy or rude!

"It's not like simple layout switch". Actually, it is! Keyboard drivers in Windows, MacOS, or Linux and even the DOS code page settings all do exactly that! All keyboards send the same scan codes for the same key locations, it's down to the keyboard driver to translate those codes into the correct character symbols shown on the keys.

"One layout is used on Linux then keys sent to FPGA where core expects the US layout to convert it to computer specific layout. Changing layout on Linux means mess the FPGA core which doesn't expect it". This is why you do not hard code for the standard US layout, they are missing the extra key that is present on most layouts globally! If you need to hard code it then hard code it to the international layout that has the extra key, the US keyboards would still work in that case. In fact the US international keyboard does have that key, so if you had followed your own advice of using an international keyboard in the first place we would not be in this situation with an important key not working for DOS on the UK keyboard!

TL;DR From your own admittance you have hard coded the core to accept scan codes from a standard US keyboard which does not include a key found on keyboards from most other countries. The fix should be simple, add the one extra scan code of the missing key into the scan code table in your core. The DOS code page setting deals with the translations from there on. Surely one extra entry into the table and making the core do one extra iteration in the loop to check those codes can not cause the mess in the FPGA core that you claim!

thejpster commented 4 years ago

@Galbi3000: please be kind.

Ok, so looking at the main input.cpp file, I can see ev2ps2, which appears to convert Linux events into PS/2 scan-codes. Running sudo evtest on my Linux box and testing a few keys on my UK keyboard shows that:

This corresponds with http://www.quadibloc.com/comp/scan.htm. Now if we look at the ev2ps2 mapping table in input.cpp:

So, my suggested patch is simply:

diff --git a/input.cpp b/input.cpp
index 8b5ddbc..ce8bbb0 100644
--- a/input.cpp
+++ b/input.cpp
@@ -382,7 +382,7 @@ static const int ev2ps2[] =
        0x71, //83  KEY_KPDOT
        NONE, //84  ???
        NONE, //85  KEY_ZENKAKU
-       NONE, //86  KEY_102ND
+       0x61, //86  KEY_102ND
        0x78, //87  KEY_F11
        0x07, //88  KEY_F12
        NONE, //89  KEY_RO

I applied this patch, rebuild MiSTer, and it now works :)

image

thejpster commented 4 years ago

Opened https://github.com/MiSTer-devel/Main_MiSTer/pull/172

Galbi3000 commented 4 years ago

@Galbi3000: please be kind.

Well, it was in response to what I perceived as an unkind suggestion and denial of the issue. I could have been worse, and I was in early drafts of the reply, it took me 3 hours to write! lol

I applaud you with your fix though. Well done :)