Wrong keys in Xserver

[guraltsev]

I was extremely happy that EPKL worked well with Windows-based Xservers. I use them to run GUI programs in WSL and in cygwin. Before, I needed to go through configuring keyboards manually in the XServer through a set of command line options. Now I can just run it in default mode and EPKL then sends the correct keys there. Extra perk: the XServer layout is the same of the active windows one. Before that, even after you configured it, it still was not synced with the windows one and that could be confusing.

However, now I encounctered a problem: the Del PgUp, PgUp,Home,End keys send numbers or a period instead of doing what they should. The keys they send are . 9 3 7 1 respectively. This does not depend on the layout! It happens for Colemak, Qwerty, and Rulemak.

Interestingly enough issueing these commands through the extended layout accessed through CapsLock works well. That is actually how am surviving for now.

A contributing factor might be that I am a laptop: It is a 15 inch that does not have a number pad but the keys I cited are on a separate column to the right of the enter button.

[guraltsev]

I found these two bug reports that seem related: https://github.com/DreymaR/BigBagKbdTrixPKL/issues/28 and https://github.com/DreymaR/BigBagKbdTrixPKL/issues/18

I experimented with the AHK key log and here is what I get when pressing Home:

24  147 h   d   2.14    Home            
24  047 i   d   0.01    NumpadHome      
24  047 i   u   0.00    NumpadHome      
24  147 h   u   0.08    Home 

It seems that instead of the home button it sends the NumpadHome and for whatever reason the Xserver is convinced that the numlock is active and interprets it as a number. Probably if I had a NumLock key I would make it work but I don't on a laptop so I am stuck. Probably the way to fix this is to remap Home to actual Home and not to NumpadHome

[guraltsev]

I also tried weaking the Xserver itself. If I disable the numlock programmatically by using the xnumlock command it gets disabled but it re-enables itself as soon as I click the Home key

[guraltsev]

I have found a workaround for this!

In the file EPKL_Layouts_Default.ini the lines responsible for remapping the concerned keys are:

QWINS = INSERT      VirtualKey      ; SC152: Ins
QWDEL = DELETE      VirtualKey      ; SC153: Del
QWHOM = HOME        VirtualKey      ; SC147: Home
QWEND = END         VirtualKey      ; SC14f: End
QWPGU = PRIOR       VirtualKey      ; SC149: PgUp
QWPGD = NEXT        VirtualKey      ; SC151: PgDn

It is sufficient to comment them out. Make sure to make a copy of that file first! Note that this might break those keys in extended layouts and whatnot. Be careful!

After that the AHK key log is simpler:

74  03F i   u   0.00    F5              
74  03F h   u   0.06    F5              
24  147     d   0.66    Home            
24  147     u   0.08    Home            
74  03F h   d   0.89    F5         

[DreymaR]

Hopefully good news: In the latest commit 22af93a I've added a check for the six affected keys that all have a counterpart on the NumPad in addition to their normal version: Home/End/Insert/Delete/PgUp/PgDn. When one of these is sent from a VK (Virtual Key) mapping, the normal version of them is now sent rather than the NumPad one – so, a key mapped to Home VKey will now produce Scan Code 147 not SC047 as it used to.

This issue wasn't a bug in EPKL per se, but a result of an unexpected behavior in Autohotkey. The VK codes for the affected keys are degenerate, which apparently is an advantage for Windows in some contexts. But AHK then chooses to send the NumPad version of them when asked to send their VK code, which in my view is unintuitive.

The issue did not affect Extend mappings since these are not sent by VK but as named keys, e.g., {Home}.