Please add Scancodes for Koreans.

[5ooooo]

Hello !! add two codes below to scancode.cpp, it will be helpful to Koreans.

SC_HANJA = 0x71, // (Korean keyboard - Hanja Key) SC_HANGUL = 0x72, // (Korean keyboard - Hangul/English Key)

[5ooooo]

And the keys listed above (HANJA, HANGUL) don't fire KeyDown events in Windows 10 OS. Can "capsaicin" emulate them to be KeyDown + KeyUp events in specific keys when a KeyUp event fire?

[cajhin]

Hi 500k

Thanks for the feedback. This is an area that I never developed, since I don't have all the keyboards from around the world. My command of the Korean language is a bit underdeveloped, too :)

I've added labels for your two keys and uploaded release v56. There are no real standards for all those special international keys. I followed the FireFox spec, which defines: 0x71 = "LANG2" 0x72 = "LANG1"

Note that if you need additional keys, now all unlabeled keys get a default label like "SC_0XA3". [ESC]+[C] prints a list of all labels.

I hope that makes it usable for you. If not, just say so.

[cajhin]

and about your 2nd comment: I don't understand, if the key does not fire a key-down on keypress, how does Windows see it? Never heard about a key firing only key-up. Did you check with the capsicain debug log if really only key-up is incoming?

[lihz]

Hi,

I am not this issuer, but I am leaving a comment as someone who is very interested in this topic.

0. Make == key press == KeyDown evnet Break == key release == KeyUp event

1. I don't know why the issuer said "don't fire KeyDown events". From what I've checked it should be expressed as "don't fire KeyUp event". Since the Make ScanCodes of these two keys are 0xF1, 0xF2, Make/Break is divided based on 0x80, so I guess it was expressed like this. However, if check in Windows OS, these two keys are related to language switching, and have no Break (key release) scan code defined. Therefore, these two keys only trigger an event when the key is pressed and no event when released.

2. For this reason, I/He cannot use these two keys by re-mapping them as Modifers. Unfortunately, these two keys on a Korean keyboard has a very good physical location to use as a Modifer.

3. I've checked with many (or almost all) libraries, none of them detect KeyUp events for these two keys. I think the reason for this is that most keyboard related libraries rely on scan codes generated by very low level drivers. In other words, if this Scan Code does not occur, the library cannot detect whether the key has been released.

4. I will use "Interception Library" to check, but it is not hopeful.

[cajhin]

Did you check what capsicain logs in debug mode (press [ESC]+[D])? When you hit [E] you see make and break, like [Ev =12 0] [E^ =12 1]

What is the output for the two keys? If there is only a ..v... without an ...^.. then you're probably out of luck. (note: the unused high scancodes F0..FF are mapped internally to capsicain's virtual modifiers. That might cause confusion if the Korean keys really send 0xF1).

If there is no break sent for these keys, I wonder how they work. Is it really a single-purpose key that triggers one action only, in other words, can it not be used like a shift key that you use in combination with other keys?

[lihz]

Hi,

---

Capsicain v56 (Release build)

Release all keys now...

ACTIVE LAYER: 1 (qwertzj-kingcon) ini version: 52b

FEATURES OFF: Z <-> Y ON: LShift + RShift -> ShiftLock ON: LAlt + RAlt -> Alt ON: Alt <-> Win for Apple keyboards ON: Left Control and Win block alpha key mapping ('Ctrl + C is never changed') OFF: Process only the keyboard that sent the first key

starting AHK... Not. 'file/path does not exist: autohotkey.exe'

[ESC] + [X] to stop. [ESC] + [H] for Help

capsicain running.... new keyboard: IBM keyboard

::DEBUG mode: ON. [D^ =20 1] [M:0] (0 ms) -- >(blocked D UP: was not down)> (0 ms). ESC^ . [Ev =12 0] [M:0] (0 ms) -- {Ev} (0 ms). [E^ =12 1] [M:0] (0 ms) -- {E^} (0 ms). [LANG2^ =71 1] [M:0] (0 ms) -- >(blocked LANG2 UP: was not down)> (0 ms). [LANG1^ =72 1] [M:0] (0 ms) -- >(blocked LANG1 UP: was not down)> (0 ms)

[cajhin]

weird. As I understand it, this means the two special keys are not usable as modifiers, they can only be used to "tap to switch language". capsicain actually seems to cause a problem here. It considers "up without previous down" a mistake, and drops the 'key up' event. I could hardcode an excecption for that but not sure anyone cares.

[5ooooo]

The background for registering the second comment is that the x71 and x72 keys were not properly recognized by the application running in the Windows 10 + X11 server environment. (like VcXsrv or Xming)

This means that the x71 and x72 keys cannot be used as language switching roles in applications in the Windwos 10 + X11 environment.

So, I partially modified the Capsicain v55 source code and confirmed that the keys operate normally in the X11 environment after simulating as if the Down Event occurred first when the Up Event occurred.

It is presumed that the cause of the problem is that only the Up Event occurs for the two keys (x71, x72) in Windows 10.

Thanks to the release of the Capsicain source code I'm grateful for being able to solve the problem I was having with just a few code modifications.

Not many people care, but I'm sure there are people who have the same problem as me. so i've suggested this in the hope that this option will be added.

At least that's because Capsicain(with modified code) was the only solution among the many alternatives I've seen on Windows 10.

"" I used Google Translator because my English is not good. Therefore, there may be rude expressions. I'm sorry about this.

[cajhin]

Google Translator has become very very good. And there were no rude expressions (other than 'Xming'). If you made the code changes in one place, can you post the code snippet here? I might put it into the main branch if it solves a real problem.

[cajhin]

note: added the official labels for Hangul and Hanja "LANG1" and "LANG2". Also, you can now reference unlabeled keys with their scancode, like "SC_0X74". ESC+C for a list of all Codes