Japanese Keyboard Issues [and more CJK discussions] #2572
Comments
|
Thanks for trying to report the issue. I am not able to reproduce the problem with the Grave key on a US keyboard, so it may be applicable to a Japanese keyboard only. As I don't have a Japanese keyboard yet, perhaps someone with a Japanese keyboard can try to reproduce the said problem, or I can check this again when I get a Japanese keyboard. |
|
@Wengier Thank you for your confirmation, and I appreciate it very much that you purchased a Japanese keyboard. |
|
@maron2000 You are very welcome. I am personally interested in the Japanese culture too, and also hope that Japanese support in DOSBox-X can get better in the future. |
|
@Wengier SDL1 version seems that it treats those keys as Unknown. For SDL2 version, the keys also cannot be recognized using the BUILT-IN KEYB command, but using FreeDOS KEYB (v2.01) seems to work. Step 1. Edit mapper-dosbox-x.map Step 2. Execute KEYB command (FreeDOS v2.01) Edit: Updated the question since I found a workaround using SDL2 version. |
|
@maron2000 I will definitely check this when I get the Japanese keyboard. Meanwhile, I am adding Japanese EGA mode in #2576, and in this mode Japanese characters can be displayed fine in addition to TTF output or PC-98 mode. You can try the updated Windows binary below and just set machine=jega and country=81,932: |
|
@maron2000 I have also added the DOS/V emulation via |
|
@Wengier One thing I see is that the highlighted text are blinking. I think it doesn't in the actual machine so would you check it? Used command
|
|
@maron2000 Thanks for the fonts you posted. I have updated the default fonts accordingly. But you can specify another font with the jfontsbcs and jfontdbcs options in [render] section of dosbox-x.conf. A screenshot is available below:
As for the blinking text (in JEGA mode), I think it is a setting issue. There is a setting "high intensity blinking" option (in [video] section), and you may want to set it to "false" and see the result (or toggle it from the menu: "Video" => "Text mode" => "High intensity: background color"). In any case, you have tried the updated DOSBox-X build with updated default fonts: |
|
@Wengier |
|
@maron2000 It looks like that FILMTN (and probably similar software) uses low ASCII characters to show box-drawing characters. I have added support for this, and the normal box drawing characters in the welcome messages will be automatically converted to such characters in JP mode too (even in standard mode with code page 932 and |
|
@maron2000 I have also added support for system input methods (IME) in Windows SDL1 builds, so that you can directly enter DBCS character into the DOSBox-X window, and I can confirm it works for both Simplified and Traditional Chinese input methods. I will test more on the Japanese IME support when I get the Japanese keyboard. The updated Windows build is available from the same link above. |
|
@Wengier |
|
@maron2000 I would expect IME support to work the same way in DOSBox-X as in for example Notepad, and this is indeed the case for Simplified and Traditional Chinese input methods. Japanese input methods may have further requirements though, either in the system level or in the code level. |
|
@Wengier I tried the 0.83.15 (SDL1) git commit e61a970 build. Step 1. Edit Step 2. Step 3.
You can see in the screenshot below that the two backslash(yen) keys on JP keyboards are recognized. The key allocation of the built-in KEYB command have some problems, such as the backslash keys aren't recognized, etc. All of the above maybe applies to DOSBox-X in DOS/V mode, but keys mapped is largely different and I think we have to prepare a dedicated Anyway, I think it is a good progress toward using SDL1 version with non-US keyboards. |
|
@maron2000 I finally got the USB Japanese keyboard, which is a portable USB keyboard without for example the Numpads, and I am still in the process of getting familiar with it. Apparently the difference between US and JP keyboard layout is not really small, and since it is a portable keyboard, it may be different from your full Japanese keyboard in some ways. For example, I was not able to reproduce the issue that Hankaku/Zenkaku key acts as if it is continuously pressed as you originally described (similar to when I was using the US keyboard layout). As for the "Unknown" key issue, I think it may be related to the "usescancodes" setting. Can you set the option Also, I would like to mention that DOSBox-X already supports a single mapper file that contains key codes for both SDL1 and SDL2 builds, in sections named [SDL1] and [SDL2] respectively. If there are things which are very different from existing ones, adding a new section can be a solution too apart from using a separate mapper file. |
|
Probably, even with a US keyboard, the behavior of the "hankaku/zenkaku" key and the "Caps Lock" key can be confirmed by changing the keyboard driver. (The same applies to "katakana hiragana" as well as keys that are treated as being held down on a Japanese keyboard.) For Win10 If it doesn't work, add [Japanese QWERTY] from [Add Keyboard] in English. What if you start dosbox -x in this state? By the way, the method of using the keyb command is that even with SDL1, if it is 0.83.14 or earlier, you can enter "Yen" or "_" by creating a mapper and preparing jp.kl that matches. |
|
@Wengier @Kurist2010 I tried it on my Win 8.1 pro laptop. I'll try it on Win 10 Pro tomorrow, and see if anything changes. |
|
Thanks both @Kurist2010 and @maron2000 for checking out the issue. With the correct keyboard layout set I could reproduce the issue that the Hankaku/Zenkaku key being continuously typed on my Windows 10 computer too, and I think it is already fixed. Please check out the updated builds:
Thanks for reporting this! |
|
It is the result of using update. [dos] The log of this result is excerpted. It recognizes a Japanese keyboard, but is finally set to the US layout. The language of Win10 of the host is deleted except Japanese. |
|
@Wengier Another problem is that the grave key is now recognized as backslash(yen) key, instead of grave key. Pretty strange because the mapper tool properly recognizes the key as "Grave key", as shown in the screenshot below.
|
|
@Wengier The following is a screenshot of FEP (IME for DOS) running on DOSBox-X SDL1 (v0.83.15).
|
|
@maron2000 I think I have already fixed the issue that the grave key got "stuck" in normal mode as you said. But pressing this key does produce the grave character here, not the Yen symbol. Meanwhile, I am interested in the FEP (IME for DOS) program you mentioned. Can you upload it or send it to me? Thanks! In any case, the updated Windows builds are available from:
|
|
@Wengier |
|
When keycode.exe is executed with jp.kl loaded by keyb.exe, the scan code is 115 and it seems to be in the key repeat state. |
|
@Kurist2010 The screenshot below shows the commands I typed since start-up of DOSBox-X. Options:
|
|
@ maron2000 The state where keyb is not resident at first. This is normal.(scan code 41) Next, the result is that keyb is resident and the half-width / full-width key is pressed once. |
|
@Kurist2010 Tried with 0.83.15 pre-release SDL2 version. |
|
This is the case when only 0.83.15 pre-release dosbox-x.exe is put in the environment using 0.83.14 (x64) and started (confirmed environment). However, HANKAKU display does not respond to hankaku / zenkaku keys. (scan = 41 is displayed) |
|
@maron2000 Thanks for the WX3 files. I have installed it accordingly (using JEGA machine type), and since WXK.SYS and WX3.SYS appear to require KKCFUNC.SYS which is not in the package, I decided to use the KKCFUNC.SYS driver found in IBM DOS J5.00/V, and then both WXK.SYS /a5 and WX3.SYS appear to load successfully. But I wonder how to activate the button line on the screen and switch to Kanji input in this case? A screenshot is available below:
Meanwhile, in JEGA mode you can now use the right Ctrl key to toggle between romaji and kana input mode. The updated DOSBox-X builds are available from:
I will also take a look at the possible issues with the built-in KEYB command. |
|
@nanshiki I suspected an issue specific to SDL-drawn menu OpenGL mode, but I tested and in both Windows SDL2 build and inside my Fedora VM (both use SDL-drawn menu) DOSBox-X seems to render Japanese (or Chinese) text just fine in such case (using OpenGL output), so I am really not sure why (I never seen such an issue with the latest code in either environment myself). By the way, is it possible to make a |
|
@nanshiki You mentioned Debian and Ubuntu, and Fedora above, all are Linux systems. Have you tried Windows SDL2 builds which also use SDL-drawn menu, and set it to OpenGL output and see if the issue also occurs there? Thanks a lot for the addition of linux_symbol_14. |
|
@Wengier This problem occurs when using opengl on Windows SDL2 version. |
|
@nanshiki Strange. I wonder if it is caused by e.g. system locale settings? In OpenGL SDL-drawn mode the MenuDrawTextChar function (in sdlmain.cpp) calls the UpdateSDLDrawDBCSTexture function (in output_opengl.cpp) for DBCS textures (see https://github.com/joncampbell123/dosbox-x/blob/master/src/output/output_opengl.cpp#L523), which render DBCS characters fine in my systems. But perhaps your system locale is Japanese, and I wonder if anything will change from this? |
|
@Wengier After calling UpdateSDLDrawDBCSTexture () with MenuDrawTextChar () in sdlmain.cpp if ((IS_PC98_ARCH || IS_JEGA_ARCH || isDBCSCP ()) && control-> opt_lang.size () && (c ||! Check)) {is true, the DBCS font texture will be used, but control->opt_lang will not be true because it is empty unless specified with the -lang command line option. |
|
@nanshiki Thanks a lot for catching this. Indeed, I almost always use the -lang option myself for testing this, so I never noticed this before. I even tried to switch my Windows system locale to Japanese and restart with no changes. I have hopefully fixed this in the code so that the "language" config option case is covered as well. Thanks again! |
|
@maron2000 According the feedbacks, international keyboards should certainly work better with the latest code than the 0.83.15 version. Meanwhile, I have heard report that the following (single) key may not work properly (the reporter uses the Italian keyboard layout):
Can you take a look at it? Thanks. |
|
@Wengier If possible, please also ask the person of the Italian keyboard to provide a screenshot of Edit: I assume the issue is regarding Windows version. If not, please inform me which version it is. Thx, |
|
@maron2000 The person with the Italian keyboard has replied that the mapper key code (for kn=-) is 0xbd. He is using Windows as you had assumed.
|
|
@Wengier Can you also confirm the codes for Keypad-Divide as well? (or direct me to the thread where the person reported the issue) I uploaded the fix for your reference. |
|
@maron2000 He seems to suggest that the codes for both keys are the same. I hope there is (eventually) a non-tentative fix for this issue. |
|
@Wengier I changed the keyboard setting to Italian, and the mapper returned codes as below when I pressed KP-divide, which is different from minus key. Edit: The link below is a test fix version. May not work if SDL1 returns identical codes for non-us slash key and KP-divide key. |
|
@maron2000 He had made corrections - the codes for them are not the same after all. According to his new message, the Numpad - returns 0x6d and the Numpad / returns 0x6f. So 0x6f is the expected key code for the KP-divided as you also showed. Is the above fix is still tentative with this information? |
|
@maron2000 Also, I have added new help message for IMGMOUNT command regarding the use of partidx=# option for mounting specified partition. Can you check the Japanese messages for this command and update them if necessary? Thanks! |
|
@maron2000 The parameter https://www.differencebetween.com/difference-between-primary-partition-and-vs-logical-partition/ Also, according to the feedback the fix works fine, which is great. |
|
@Wengier Thanks for the info and feedback. Glad to hear that it worked! |
|
@Wengier Fixes DOS/V settings and V-Text XGA and 24 pixel font related issues. #2791 For vtext2, video mode 0x78 is specified when switching, but then 0x70 is entered for 0040:0049. Therefore, when the cls command is executed, the original 0x78 should be specified. Currently, the only way to set vtext and vtext2 is to set the video mode to 0x70 or 0x78 using an external command. |
|
@Wengier Added support for IME input in SDL2. #2816 |
IME code in wayland is guarded with #ifdef SDL_USE_IME, so you may need to recompile SDL2 with SDL_USE_IME defined. |
|
@roytam1 Thank you, I built and installed SDL2 from source on Fedora and was able to use the IME when I ran the test program. |
|
@nanshiki IME support for SDL2 builds is very helpful - it works here, and I just fixed a minor issue for the space key for non-Japanese IMEs. |
|
@nanshiki So I added a command VTEXT to view or change the V-text mode of DOS/V, e.g.
|
|
The only problem seems that GetWindowsFont() may not work correctly with 24-pixel SBCS fonts in Japanese DOS/V mode. This can be demonstrated with the following command-line:
Screenshot:
This can be solved by setting
As a workaround, the function GetWindowsFont() is disabled for 24-pixel SBCS fonts unless |
|
{} が抜けています。 bool MakeSbcs24Font() {
InitFontHandle();
bool fail=false;
for(Bitu code = 0 ; code < 256 ; code++) {
if(!GetWindowsFont(code, &jfont_sbcs_24[code * 24 * 2], 12, 24)) { // <-- {
fail=true;
break;
} // <-- }
} |
|
@nanshiki Fixed. ありがとうございます. |
Describe the bug
Hankaku/Zenkaku key of JP106 keyboard (Grave accent key(`) in mapper tool) acts as if it is continuously pressed, despite it is released.
Edit: Replaced example of JP keyboard layout. (Image taken from here)
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Grave accent (`) shall be typed only when Hankaku/Zenkaku key is pressed.
Screenshots
Environment (please complete the following information):
Additional context
I don't know whether this is a problem applicable to Japanese keyboards only.
The text was updated successfully, but these errors were encountered: