kmonad/kmonad

Improve Windows KeyIO API

Ouverte

#10 ouverte le 13 oct. 2019

 (2 commentaires) (0 réaction) (0 personne assignée)Haskell (336 forks)batch import
Windowshelp wanted

Métriques du dépôt

Stars
 (4 979 étoiles)
Métriques de merge PR
 (Merge moyen 4j 7h) (1 PR mergée en 30 j)

Description

The low level Linux API to the operating system allows for a user to choose which keyboard should be grabbed by KMonad. This allows for different mappings on different devices, and does not automatically rob the OS of all raw input.

Due to limitations with the C-code and the Win32 API the current C-implementation for Windows is extremely naive, and needs to capture all raw input. The reasons for this are as follows:

Windows offers 2 different API's to keyboard events, using keyboard-hooks that install a callback and the RawInput API. The Keyboard-hook based API will allow you to intercept events and block them from further processing by windows, but does not distinguish between input sources. The RawInput API lets you register a particular type of raw input, and then distinguish between input sources, but is does not allow you to block processing of input events.

Therefore:

  • using only a keyboard hook will not let you distinguish between input sources (current implementation).
  • using RawInput will not let you block events (making it useless on its own).

Potential solution: Combine the RawInput and keyboard hook API, using an approach similiar to one described here. However, this becomes exponentially more complicated in the following ways:

  • We'll need to set up a much more complicated c-module that registers inputs from both API's, coregisters them despite having no order guarantees, and deals elegantly with missing events happening sometimes. (according to that article).
  • This combined approach can't use a low-level hook, but needs a normal keyboard hook, which as a consequence means you can no longer keep your hook in a simple C-file, but need to create a .dll file for the keyboard hook so that it can be injected into windows namespaces (or something like that).
  • Not sure if/how, but this might also complicate the FFI from haskell and the compilation process.

Gotta love windows.

If anyone has some serious Win32 programming skills (or desire to have those skills) it would be great if they could help out with this. Of course, I'd also be very happy to hear any other potential solution.

Guide contributeur