I would like to know how people are remapping their keyboard in Guix Systems, especially when they are using it in conjunction with a touch pad nearby. I wanted to remap the keyboard on my laptop, and I installed keyd package. It remapped the keys as I wanted, but the disable-while-typing (DWT) coordination with the touchpad was lost.
I learned that keyd creates a virtual keyboard, that DWT works for keyboard and touchpad marked as internal, but that this virtual keyboard is not marked internal. On the internet, the solution is to create
I am about to create a custom package inheriting from libinput with output of Path 2 of Content 1. I will also replace all occurrences of libinput package in the package dependency graph and inputs to all the services. This sounds a lot of work for such a common task of keyboard remapping, and I am wondering if a simpler solution has been known. I would appreciate your kind suggestions.
Unfortunately don’t have a solution to offer, but this post did make me check and realize DWT isn’t working for me either as a Keyd user. I had no clue that was a side effect of using Keyd. I guess it hasn’t bothered me enough since i didn’t even realize it was broken, but i would be interested in what the best way is to solve this as well.
First off, hyprland and most of the other wayland compositors rely on libinput-minimal. it’s possible that you could get lucky, replace the inputs here, hit like 90% of the issues and … just end up with a few weird things? lol
if you do cat $libinputthings | strings | sort | uniq | grep '/gnu/store or something along those lines with libinput, does that cause /gnu/store/<HASH> to show up?
do you know if it’s libinput-minimal that causes the issue?
The libinput that’s signaling to alter touchpad behavior needs to be fairly priviledged i think
I’m probably dumber than I look, since offhand I really can’t explain how Wayland is functionally distinct from X11. I usually need to refer to diagrams to grok this stuff in the moment
This may help: Section 8 explains why package transformations are tough at the operating-system or home-environment level.
basically, if you want an overlay, you need to (define my-operating-system (operating-system ...)) then reopen it with another definition, where you inherit, then modify the packages using package-input-rewriting/spec… i think.
It would be better to map over the list of packages first, then pass that to the OS.
It may work better if you reuse/recreate the way packages are identified by spec.
I haven’t done this yet. I’ve only barely messed with transformations in code, so I may be off-base and idk what the performance would be.
The package you replace them with may need to be a const. i’m not sure.
There’s an example of package-input-rewriting on gwl
There may be a clever way to get scheme to redefine the package’s symbol… but idk. Tropin probably would’ve done something simpler there. It looks like it requires a lot of control.