Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Microsoft PowerToys Keyboard Manager seems to distinguish between L_SHIFT and R_SHIFT #2

Open
dumblob opened this issue Mar 5, 2021 · 2 comments

Comments

@dumblob
Copy link
Owner

dumblob commented Mar 5, 2021

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:

  1. investigate whether we could use Microsoft PowerToys Keyboard Manager to make ULKL layout (which relies on distinguishing L_SHIFT from R_SHIFT) work
    1. 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)
    2. 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).

@dumblob
Copy link
Owner Author

dumblob commented Mar 7, 2021

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).

@dumblob
Copy link
Owner Author

dumblob commented Dec 6, 2022

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:

  1. Windows login screen after boot
  2. Windows login screen after locking the screen from a logged-in user (non-admin) session
  3. M$ Office (the native version, not the web version) - Word & Excel & Powerpoint at the least
  4. M$ Edge browser (yes, the new chromium-based one)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant