4 ms·

Project Mouse Tailor

34 points by marbu 5y ago

mrtweetyhack 5y ago
zamadatix 5y ago
Not sure about drag lock (hadn't heard of it before this) but at least button mapping doesn't seem like something that should be done by either the display protocol or the DE in the first place. https://github.com/sezanzeb/input-remapper https://github.com/sezanzeb/input-remapper will do it at the input layer, similar to how this works but via software.
- mbreese 5y ago
  Drag lock is for dragging and dropping objects without needing to hold down a mouse button. So, for the OP, if you click button D (whatever that is), instead of a click, you toggle drag lock. So every captured MOUSE_MOVE after that also has a BTN_A_DOWN attached to the event. From the linked library, it looks like you could setup this logic, but it is pretty complex. But I think you could do it with a combination of the set and if_eq macros. But it’s pretty cool to see how you could also accomplish this and fake out the computer using a bit of hardware hacking. (I know, it software running on a teensy, but still…)
- franga2000 5y ago
  Sure, remapping "belongs" to the input layer, but there are use-cases that aren't possible if you do this. I've had a few situations in the past where I had to do window-level button remapping. I had programs that had hard-coded keyboard shortcuts for keys that my keyboard simply didn't have and remapping them for the whole system would've screwed up every other program. If you go further and expand input remapping to also inclue macros you'll also soon find the need to send input directly to a window. There are also many cases where a simple remap won't do since there isn't a single "originating" input event (like remapping joystick movement to WASD or faking inputs from non-input device events). This makes any such API fairly complex and you'd have to be implementing something like it in the compositor/window manager/DE anyways, so why bother also doing it at the input layer? Where Wayland went wrong is ignoring these use cases and putting the burden of making APIs for them on compositors, which of course couldn't agree on anything, so now we have nothing. Evdev works at a very low level, so many things aren't possible, libinput doesn't expose its APIs externally anyways and the only compositor with even rudimentary input mapping support is KWin and that barely works.
schappim 5y ago
For those who are wondering "Project Mouse Tailor" is a USB hardware solution (based on Teensy 4.1) with the aim of adding mouse button remapping and "Drag Lock". "Drag Lock" is a feature when you can "lock" onto a screen object (window, icon etc), so that it can be dragged without having to hold down a mouse button. The op is doing this in hardware due to many Linux Distros changing from X11 to Wayland.
IntrepidWorm 5y ago
I have to say, I was a bit crestfallen when this wasn't in fact an article about tiny rodent suits.

34 points by marbu 5y ago

Not sure about drag lock (hadn't heard of it before this) but at least button mapping doesn't seem like something that should be done by either the display protocol or the DE in the first place. https://github.com/sezanzeb/input-remapper https://github.com/sezanzeb/input-remapper will do it at the input layer, similar to how this works but via software.

mbreese 5y ago
Drag lock is for dragging and dropping objects without needing to hold down a mouse button. So, for the OP, if you click button D (whatever that is), instead of a click, you toggle drag lock. So every captured MOUSE_MOVE after that also has a BTN_A_DOWN attached to the event. From the linked library, it looks like you could setup this logic, but it is pretty complex. But I think you could do it with a combination of the set and if_eq macros. But it’s pretty cool to see how you could also accomplish this and fake out the computer using a bit of hardware hacking. (I know, it software running on a teensy, but still…)
franga2000 5y ago
Sure, remapping "belongs" to the input layer, but there are use-cases that aren't possible if you do this. I've had a few situations in the past where I had to do window-level button remapping. I had programs that had hard-coded keyboard shortcuts for keys that my keyboard simply didn't have and remapping them for the whole system would've screwed up every other program. If you go further and expand input remapping to also inclue macros you'll also soon find the need to send input directly to a window. There are also many cases where a simple remap won't do since there isn't a single "originating" input event (like remapping joystick movement to WASD or faking inputs from non-input device events). This makes any such API fairly complex and you'd have to be implementing something like it in the compositor/window manager/DE anyways, so why bother also doing it at the input layer? Where Wayland went wrong is ignoring these use cases and putting the burden of making APIs for them on compositors, which of course couldn't agree on anything, so now we have nothing. Evdev works at a very low level, so many things aren't possible, libinput doesn't expose its APIs externally anyways and the only compositor with even rudimentary input mapping support is KWin and that barely works.

schappim 5y ago

For those who are wondering "Project Mouse Tailor" is a USB hardware solution (based on Teensy 4.1) with the aim of adding mouse button remapping and "Drag Lock". "Drag Lock" is a feature when you can "lock" onto a screen object (window, icon etc), so that it can be dragged without having to hold down a mouse button. The op is doing this in hardware due to many Linux Distros changing from X11 to Wayland.

IntrepidWorm 5y ago

I have to say, I was a bit crestfallen when this wasn't in fact an article about tiny rodent suits.