xinput is a commandline tool to change X device properties. Specifically, it's a generic interface to change X input driver configuration at run-time, used primarily in the absence of a desktop environment or just for testing things. But there's a feature of xinput that many don't appear to know: it resolves device and property names correctly. So plenty of times you see advice to run a command like this:
xinput set-prop 15 281 1This is bad advice, it's almost impossible to figure out what this is supposed to do, it depends on the device ID never changing (spoiler: it will) and the property number never changing (spoiler: it will). Worst case, you may suddenly end up setting a different property on a different device and you won't even notice. Instead, just use the built-in name resolution features of xinput:
xinput set-prop "SynPS/2 Synaptics TouchPad" "libinput Tapping Enabled" 1This command will work regardless of the device ID for the touchpad and regardless of the property number. Plus it's self-documenting. This has been possible for many many years, so please stop using the number-only approach.
3 comments:
I do not think using names is the best solution either, because names are not unique (if you have more than one device of the same kind they all will have the same name) and I do not believe we made any commitment to never change names. xinput should offer other ways to identify devices: sysfs path and/or "phys" property. While they too may change between releases (we try not to) they should be at least unique at any given boot cycle.
@Dmitry: the drivers all initialize the "Device Node" property that is filled with the event node path. From that one can work their way back to whatever sysfs property is needed.
But this the wrong feature for xinput. If you have multiple identical devices or you have device names change across kernel releases then you're well past the capabilities of a debugging tool that just works for 90% of the use-cases. That's why GNOME doesn't use xinput but rather the X API behind it. And the code itself is simple enough that the property bits could just be lifted out of xinput (MIT license anyway) into whatever custom configuration script is needed.
Peter, I missed the fact that xinput is positioned to be a testing tool, not generic configuration tool that should be used in actual setups.
Post a Comment