It's arguable whether this is The Right Thing and should we instead be providing some declarative/structured way to add local device quirks. That said, upstream seem quite firm on the idea that local quirks are temporary and should be pushed to them for distribution in later libinput versions, so one could make a case for intentionally keeping our quirks in the same text-based format (ini files) as they will expect.

I think this is the right thing to do. /etc directory is declarative if you are using NixOS. Putting configuration in libinput's closure leads to needless rebuilds as well. I actually thought we set this globally for Meson! While autoconf defaults sysconfdir to /etc, Meson defaults to $prefix/etc. We should try to make this more consistent.

I think this is the right thing to do. /etc directory is declarative if you are using NixOS. Putting configuration in libinput's closure leads to needless rebuilds as well. I actually thought we set this globally for Meson! While autoconf defaults sysconfdir to /etc, Meson defaults to $prefix/etc. We should try to make this more consistent.

I think you fixed something with fuse but didn't pr the change for that to happen.
Would be right to have that change though, but being careful since we have all those sysconfdir_install patches.

Even if this isn't philosophically the right solution, we need some way to add libinput quirks locally. Right now I can't use my double-click button on my RollerMouse Free3 because upstream does not have it in quirks yet, and the quirks mechanism in NixOS is broken.

Unfortunately that means that it is currently a pain (quite literally, ergonomically) to use my mouse. I'm dependent on the functioning of that button to reduce my RSI issues.

What needs to happen to get some sort of solution applied here ASAP?

@joepie91 I don't think anyone said we didn't need this fix, in the end libinput needs to be configured to find configs from /etc if we wanted to support this in the module.

@worldofpeace Right, but from the above conversation it feels to me as if this PR is going to get stuck in "what would the philosophically correct solution be" limbo while leaving the immediate issue unsolved. As this is a significant health issue, that would be a serious problem to me.

I'd rather just see an immediate solution applied (and backported to stable), and - if necessary - that solution getting replaced with a more generic/philosophically-correct one later.

I agree with @joepie19. I patched it locally, for me, by adding an overlay in /etc/nixos/configuration.nix - https://ww.telent.net/2019/10/2/light_touch_regulation , but it does need an awful lot of package rebuilding as a result

I should add that I don't have a commit bit myself, if anyone in the conversation is wondering why I haven't done it already

Please add a libinput module option as well for it.

Please add a libinput module option as well for it.

config.services.xserver.libinput.quirks = [
''
[Section touchpad pressure]
MatchUdevType=touchpad
MatchName=*SynPS/2 Synaptics TouchPad
MatchDMIModalias=dmi:*svnLENOVO:*:pvrThinkPadX1Carbon4th*
AttrPressureRange=45:40
''];

something like that, you mean? It's a good idea (I'd be happy to try it as soon as I have the bandwidth), but I think it could be tackled as a separate PR instead of coupling to this one. It's not that hard to set environment.etc."libinput/local-overrides.quirks" in configuration.nix, so although it'd maybe make things prettier/more disoverable/more semantic, it wouldn't actually unlock any new capabilities.

Yes, like that. The reason is discoverability.

Has this also been backported to stable? I'm not sure what the staging branch is for.