You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As thoroughly tested on Windows 7, there is no non-daemon way to distinguish L_SHIFT from R_SHIFT. One option to overcome this issue could be thus to:
investigate whether we could use Microsoft PowerToys Keyboard Manager to make ULKL layout (which relies on distinguishing L_SHIFT from R_SHIFT) work
either by using PowerToys KM as "prechewing filter" to produce "correct" L_SHIFT & R_SHIFT (incl. with tricky key ups and key downs and combinations)
or by using PowerToys KM to consume the output from ULKL dll and converting it to key events which are digestable by Microsoft Office, Notepad, cmd.exe etc.
From the source code of PowerToys KM it seems, that since Windows 10 the kbd kernel backend does indeed distinguish between L_SHIFT and R_SHIFT (not sure about Windows 8).
For ULKL it's totally fine if it supports only Windows 10 or newer.
Anyone who has Windows 10 and wants to spend the weekend with ULKL? We'll then discuss how to proceed efficiently (there are many gotchas in Windows regarding kbd input and debugging).
The text was updated successfully, but these errors were encountered:
Or alternatively try to use Dual Key Remap tool as it allows for configuration of when pressed alone and when pressed as a beginning of a (sub)suquence (a (sub)sequence is 2 or more keys, but not just 1 key nor 0 keys).
Yet another option would be to sacrifice L_Alt scan code and force remap R_Shift scan code to it using registry before it enters the whole hard-coded machinery in the Windows kernel. Thus potentially allowing detection of the "physical R_Shift" key pressed (now producing L_Alt) together with the "physical L_Shift".
Attempted in a1f2696 but so far untested. Anyone dare to test? Especially important is to test:
Windows login screen after boot
Windows login screen after locking the screen from a logged-in user (non-admin) session
M$ Office (the native version, not the web version) - Word & Excel & Powerpoint at the least
As thoroughly tested on Windows 7, there is no non-daemon way to distinguish L_SHIFT from R_SHIFT. One option to overcome this issue could be thus to:
From the source code of PowerToys KM it seems, that since Windows 10 the kbd kernel backend does indeed distinguish between L_SHIFT and R_SHIFT (not sure about Windows 8).
For ULKL it's totally fine if it supports only Windows 10 or newer.
Anyone who has Windows 10 and wants to spend the weekend with ULKL? We'll then discuss how to proceed efficiently (there are many gotchas in Windows regarding kbd input and debugging).
The text was updated successfully, but these errors were encountered: