[Mac] Support more identifiers for filtering devices #516
Conversation
Create a new record to store a device's identifiers/properties.
All stuff that accept "product name" are modified to accept `DeviceIdentifiers` record or it's equivalent C struct. From a user point of view, nothing has been changed - still only accepts an optional product name. Only internal API is changed to check whether this is working as intended.
Print the `DeviceIdentifiers` record to check the correctness of the struct.
Edit: For #3, I was able to force-compile C/C++ code by deleting related build objects in |
| @@ -107,7 +116,7 @@ instance HasKeyRepeatCfg SendEventCfg where keyRepeatCfg = seRepCfg | |||
|
|
|||
| data KeyInputCfg | |||
| = LinuxEvdevCfg EvdevCfg | |||
| | MacIOKitCfg IOKitCfg | |||
| | MacIOKitCfg (Maybe IOKitCfg) | |||
There was a problem hiding this comment.
Is this okay?
| dp <- deviceProperties cfg | ||
| str <- print dp | ||
| let t f dp = (D.trace ("DeviceProperites: \n" <> str) f dp) | ||
| t grabKb dp |
There was a problem hiding this comment.
Note to self: remove this debugging expressions.
|
|
||
| where | ||
| print dp = do | ||
| dp <- peek dp |
There was a problem hiding this comment.
Note to self: remove this.
Can this where section be moved to below init function? I am getting errors when I do that. I guess I am still not clear on where I can use where.
| , ("iokit-name" , KIOKitSource <$> optional textP)] | ||
| , ("iokit-name" , KIOKitSource <$> optional (textP >>= mkCfg))] | ||
| where | ||
| mkCfg n = pure $ def {_cfgProductName = n} | ||
|
|
There was a problem hiding this comment.
This is for testing only. Will write a proper parser after we get this working.
TODO: check Karabiner-Elements repo and other sites to find the corresponding macOS keycodes. It plausibly corresponds to some `International`-named keys.
426621f
to
b11ad6c
Compare
error: no type named 'path' in namespace 'std::filesystem'
|
@slotThe: Can you create a repo for dext and give me write access? Reason: To fix compilation errors, I had to modify dext's header files. I opened an issue in the official repo, but I don't think it will be fixed soon.Therefore, I fixed them in my fork. I want to move that repo into this orgnanization, so I can use that URL as the submodule's |
|
@MuhammedZakir: https://github.com/kmonad/kmonad-dext You should have an invite for the right perms. I'll try to look at the PR this weekend but I have no experience with MacOS and I'm hopeless in non-functional languages :) |
Got it. I should have asked earlier... isn't it better to do a Github-fork of official repo? [1] This way we can see when new commit are made there. [1] https://github.com/pqrs-org/Karabiner-DriverKit-VirtualHIDDevice
Okay. But if you got time, it would helpful if you could answer my doubts posted in the second post. |
Good point! Should be switched now
Will try! |
`kIOMasterPortDefault` is deprecated in macOS 12. Use `kIOMainPortDefault` in macOS 12 & above. Cast (const char *) to (char *) to inhibit "loses qualifier" warning.
2a68db0
to
939efcc
Compare
|
Should we support a list of keyboard identifiers? This is useful and doable in macOS as we already can(are) capture(ing) multiple keyboards. ;; tl;dr --
;;
;; All identifiers that are not given are considered as
;; MATCHED.
;;
;; Suppose 'all, a, b and c are keyboard identifiers, then
;;
;; variations => how they are matched.
;; ---------- ---------------------
;; ('all) => <all keyboards are captured>
;;
;; ((a)
;; (b)) => a OR b
;; ((a b)
;; (c)) => (a AND b) OR c
;; (exclude (a)) => NOT a
;; (exclude ((a)
;; (b))) => NOT (A OR b)
;; (exclude ((a b)
;; (c))) => NOT ((a AND b) OR c)
;; ((a)
;; (exclude (b))) => a OR (NOT b)
(defcfg
;; Only ONE `iokit` block is supported. You can use any of
;; the variations listed below.
;; #1: A stub for "no identifier" => capture all keyboards.
iokit ('all)
;; #2: A list of identifiers => capture matching keyboards.
;;
;; Useful to capture a single keyboard or a set of keyboards
;; matching a criteria. For example, same manufacturer, or
;; transport (usb vs bluetooth).
;;
;; All identifiers are optional, and identifiers not given
;; are considered as MATCHEd. As you can expect, more
;; identifiers make it easier to fine-tune the capturing.
;;
;; e.g. Capture keyboards if
;; product name is "some name" *AND* transport is USB
iokit (:product-name "some name"
:transport 'usb)
;; #3: A list of lists of identifiers => similiar to #2.
;;
;; More flexible version of #2. Also useful to capture only
;; specific keyboards in a single KMonad instance. An example
;; usecase is mapping a key combo to some other action, but
;; instead of pressing everything in a single keyboard, you
;; press the keys in different keyboards. This is not possible
;; with "1 keyboard per KMonad" style. This is maybe a cliche,
;; but if we already have everything to support this, why not?
;;
;; e.g. Capture keyboards if
;; product name is "nice keyboard" *AND* transport is USB
;; *OR* manufacturer is "Wierd Keyboards Limited"
iokit ((:product-name "nice keyboard" :transport 'usb)
(:manufacturer "Wierd Keyboards Limited"))
;; #4: Same as #3, but with exclusions by prepending a list
;; with `exclude`.
;;
;; Useful to exclude certain keyboards.
;;
;; e.g. Capture
;;
;; 4.1. if product name is "Apple Internal Keyboard"
iokit (exclude (:product-name "Apple Internal Keyboard"))
;; 4.2. all Apple keyboards except the internal one.
iokit ((:manufacturer "Apple Inc.")
(exclude (:product-name "Apple Internal Keyboard")))
;; 4.3. all keyboards except
;; bluetooth keyboards
;; *OR* whose product name is "some funky keyboard"
iokit (exclude ((:product-name "some funky keyboard")
(:transport 'bluetooth)))
) ;; defcfg |
|
I didn't forget this. It will take a few more weeks before I am free to work on this. Sorry! Before getting into this, I would like to know what you guys think about the question I posted above. Should we support capturing multiple devices using identifiers? I think it maybe useful for some split-keyboards. |
No worries, I can relate... ;-) On the same note let me apologize for being gone for a while too. Life fluctuates and we do what we can, and no more.
I think this is a good idea. Ideally we would have a stream of uniquely identified keys. In the case of multiple keyboards, that means keyboard-id and keycode-id. I am again starting to think about how to merge ideas from keycode refactor into master, and I will be keeping this in mind as I work on the KeyEvent representations. |
|
This may or may not be useful for your PR, but this comment seems to be affecting M2 Macs from identifying keyboards: #633 (comment) |
Notable changes: - Added `around-next-single`, a variant of `around-next` that will release its context on any change, as opposed to only on the release of the 'arounded' button. - Added default compose sequence for Ü - Added a `sticky-key` - Added `--version` (`-V`) flag - Added `+,` for "add a cedilla" - Added `:timeout-button` keyword to `tap-hold-next` and `tap-hold-next-release`, so that they can switch to a button other than the hold button when the timeout expires. - The `multi-tap` key now immediately taps the current key when another key is pressed during tapping. - Fixed compilation error under Mac, having to do with typo in Keycodes. - Fixed issue with empty-names for uinput-sinks. - Ignore SIGCHLD to deal with non-termination bug. --- This should probably be 0.5, but notable issues like [1..6] still preventing me from being comfortable with that. None of these seem completely insurmountable, though, so stay tuned :) [1]: #475 [2]: #704 [3]: #681 [4]: #716 [5]: #516 [6]: #426
DeviceIdentifiersrecordFor some reason, this is not working when a product name is given in
iokit-name. Need help!cc: @slotThe @thoelze1