Over in bug 24713 I reported a couple of drag lock problems, and this one seems to be a separate bug so, as requested, I'm making a separate bugzilla for it: If I try to make button 8 a "universal" drag lock, using xinput set-int-prop \ 'Kensington Kensington Expert Mouse' \ 'Evdev Drag Lock Buttons' 8 8 Then I can click 8 followed by 1 and I do indeed get a button 1 draglock, but to end the draglock, I am forced to click the combination of 8 followed by 1 yet again. This seems silly - I'd think that just click 1 or click 8 by itself would end the drag lock.
I looked at that yesterday while fixing bug 24713 and it should be fairly straightforward to implement. The main bits that are missing right now (and need to be added, tested and debugged) is ensuring that the right lock buttons are released on unlock and that no duplicate events are being sent. If you're interested in implementing this feature, I'll be happy to mentor you on this. Just send me an email to the address listed here.
No thanks. I don't even want to use the universal mode drag lock, I just tested it when I was trying to make button 8 be a drag lock for button 1. I'm off to try the new evdev fedora package now with that fix and see if I can finally live without an xorg.conf :-).
On a probably related note: I just tested the drag lock fix from bug 24713, and it works fine, but there is one difference with old style draglock: The pre-evdev draglock would release the lock when I pressed (in my example) either button 8 or button 1. With the evdev version, I have to press button 8 (the lock button) to release the lock (which isn't really a problem because that's the one I normally press anyway, but I thought I should mention the difference).
been open for 7 years, let's say it won't get fixed
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.