Uinput middle click not recognized #109506

New Issue

vassiliscooper · 2023-06-29T13:48:18+02:00

vassiliscooper commented

2023-06-29 13:48:18 +02:00

System Information
Operating system: Linux-6.3.8-arch1-1-x86_64-with-glibc2.37 64 Bits
Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 535.54.03

Blender Version
Broken: version: 3.5.0, branch: blender-v3.5-release, commit date: 2023-03-29 02:56, hash: 1be25cfff18b
Worked: (newest version of Blender that worked as expected)

Short description of error
I'm using a keyboard filter that grabs (gets exclusive control of) my physical inputs in order to remap them, then sends out the result through a virtual evdev device. The device itself isn't grabbed by any other process, and all other virtual events work perfectly, INCLUDING the rest of the mouse buttons. It is only middle click that doesn't work, and only in Blender (maybe another 1-2 apps but I can't recall).

I've checked and reset my keymaps. Even while this system is running, my unfiltered mouse can still use middle click in blender just fine. I've tried all sorts of combinations of programmatically generating the middle click, using evdev remapping software other than my own in case I missed some flag or permission, nothing, it's all the same. Blender consistently disregards virtual middle mouse clicks exclusively.

Exact steps for others to reproduce the error
Use any evdev-based key remapper or virtual keyboard (the mapping of one key to another is internal to the remapper and plays no role), generate a virtual middle click event (key code is BTN_MIDDLE and of type EV_KEY), then attempt to use said click in Blender. It should completely ignore it.

I'm confident any evdev-based remapper will work since I've tried plenty of apps that use evdev for this task (but aren't strictly remappers). I can only suggest MidiMonster for testing as it's the simplest I've actually tried and am using right now.

**System Information** Operating system: Linux-6.3.8-arch1-1-x86_64-with-glibc2.37 64 Bits Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 535.54.03 **Blender Version** Broken: version: 3.5.0, branch: blender-v3.5-release, commit date: 2023-03-29 02:56, hash: `1be25cfff18b` Worked: (newest version of Blender that worked as expected) **Short description of error** I'm using a keyboard filter that grabs (gets exclusive control of) my physical inputs in order to remap them, then sends out the result through a virtual evdev device. The device itself isn't grabbed by any other process, and all other virtual events work perfectly, INCLUDING the rest of the mouse buttons. It is only middle click that doesn't work, and only in Blender (maybe another 1-2 apps but I can't recall). I've checked and reset my keymaps. Even while this system is running, my unfiltered mouse can still use middle click in blender just fine. I've tried all sorts of combinations of programmatically generating the middle click, using evdev remapping software other than my own in case I missed some flag or permission, nothing, it's all the same. Blender consistently disregards virtual middle mouse clicks exclusively. **Exact steps for others to reproduce the error** Use any evdev-based key remapper or virtual keyboard (the mapping of one key to another is internal to the remapper and plays no role), generate a virtual middle click event (key code is BTN_MIDDLE and of type EV_KEY), then attempt to use said click in Blender. It should completely ignore it. I'm confident any evdev-based remapper will work since I've tried plenty of apps that use evdev for this task (but aren't strictly remappers). I can only suggest MidiMonster for testing as it's the simplest I've actually tried and am using right now.

vassiliscooper added the

labels 2023-06-29 13:48:18 +02:00

YimingWu commented

2023-06-29 16:59:12 +02:00

Does this remapped virtual device output the same event pattern as the physical one under xinput test [devide_id]? (xinput list to see device list) Does it actually click and release so it's not holding?

Another thing I can think of is that whether you have your middle key sent from the keyboard device, blender probably would want to receive from a pointer type device.

Also is this X11 or Wayland?

Does this remapped virtual device output the same event pattern as the physical one under `xinput test [devide_id]`? (`xinput list` to see device list) Does it actually click and release so it's not holding? Another thing I can think of is that whether you have your middle key sent from the keyboard device, blender probably would want to receive from a pointer type device. Also is this X11 or Wayland?

vassiliscooper commented

2023-06-29 19:41:09 +02:00

I currently have access to a bunch of different virtual devices, this includes a pointer and keyboard created by midimonster, a pointer created by my physical keyboard,and a single device that does both by my own libevdev program. All behave the exact same, as far as I've seen all middle clicks come out of the pointer devices according to xinput.

In the case of my own program, I make a single device, and evtest's list reflects that, while xinput has a separate pointer and keyboard device with the same name so, not sure what to make of that, but it doesn't seem to affect this issue at all anyways.

Does this remapped virtual device output the same event pattern as the physical one under xinput test [devide_id]? (xinput list to see device list) Does it actually click and release so it's not holding?

Yes, every virtual device I tested output the same set of:
button press 2
button release 2

Another thing I can think of is that whether you have your middle key sent from the keyboard device, blender probably would want to receive from a pointer type device.

Dedicated pointer devices and hybrid devices seem to behave the exact same, as noted above.

Also is this X11 or Wayland?

X11. Would Wayland make a difference since evdev is pre-compositor?

I currently have access to a bunch of different virtual devices, this includes a pointer and keyboard created by midimonster, a pointer created by my physical keyboard,and a single device that does both by my own libevdev program. All behave the exact same, as far as I've seen all middle clicks come out of the pointer devices according to xinput. In the case of my own program, I make a single device, and evtest's list reflects that, while xinput has a separate pointer and keyboard device with the same name so, not sure what to make of that, but it doesn't seem to affect this issue at all anyways. > Does this remapped virtual device output the same event pattern as the physical one under `xinput test [devide_id]`? (`xinput list` to see device list) Does it actually click and release so it's not holding? Yes, every virtual device I tested output the same set of: button press 2 button release 2 > Another thing I can think of is that whether you have your middle key sent from the keyboard device, blender probably would want to receive from a pointer type device. Dedicated pointer devices and hybrid devices seem to behave the exact same, as noted above. > Also is this X11 or Wayland? X11. Would Wayland make a difference since evdev is pre-compositor?

vassiliscooper changed title from ~~Uinput middle click not reckognised~~ to Uinput middle click not recognized

2023-06-30 01:26:33 +02:00

YimingWu commented

2023-06-30 05:01:35 +02:00

Noted. This is indeed quite interesting.

I would probably have to replicate the same virtual hardware setup as yours to see what exactly is going on. Could you describe how your virtual devices are set up? with script or something? I'm on linux so it should be easy to see.

Noted. This is indeed quite interesting. I would probably have to replicate the same virtual hardware setup as yours to see what exactly is going on. Could you describe how your virtual devices are set up? with script or something? I'm on linux so it should be easy to see.

vassiliscooper commented

2023-06-30 13:56:40 +02:00

It's all a bit convoluted so I can only suggest midimonster. I've been trying to make a chorded keyboard system for both qwerty and MIDI, so my own program is a total mess with a complicated config (also written in zig) and my midimonster scripts are "MIDI -> key event" translators at the moment.

Since all of them behave the same, I just made a midimonster config that takes the qwerty "Q" and turns it into a mouse2 and...

!!! oh this one WORKS?!?

Ok, clearly all previous configs have some issues in common. My guess is you were right on the pointer device having to be separate for blender to like it, and even though they appeared as separate, somehow that wasn't technically the case.

I'd still consider this a bug since it popped up so often and so silently, and it completely excludes some setups (my Wooting keyboard has this issue and I have no control over how it creates its virtual pointer). But since there's a way that works for me I'll look into what caused it and try to come up with an answer for anyone else facing this.

Here's the working config, make sure to set the right event number. I have no clue what's different than my other configs tbh, just the lack of other events (though I'm confident I have them on separate devices anyway so...very mysterious still).

`
;Put this config in a "name.cfg" file.
;After installing Midi Monster, run with:
;$ midimonster path/to/name.cfg

[evdev in]
device = /dev/input/event??
;run "evtest" with no args to find your keyboard's event number

[evdev out]
exclusive = 0
output = Mouse2 Test

[map]
in.EV_KEY.KEY_Q > out.EV_KEY.BTN_MIDDLE
`

It's all a bit convoluted so I can only suggest midimonster. I've been trying to make a chorded keyboard system for both qwerty and MIDI, so my own program is a total mess with a complicated config (also written in zig) and my midimonster scripts are "MIDI -> key event" translators at the moment. Since all of them behave the same, I just made a midimonster config that takes the qwerty "Q" and turns it into a mouse2 and... !!! oh this one WORKS?!? Ok, clearly all previous configs have some issues in common. My guess is you were right on the pointer device having to be separate for blender to like it, and even though they appeared as separate, somehow that wasn't technically the case. I'd still consider this a bug since it popped up so often and so silently, and it completely excludes some setups (my Wooting keyboard has this issue and I have no control over how it creates its virtual pointer). But since there's a way that works for me I'll look into what caused it and try to come up with an answer for anyone else facing this. Here's the working config, make sure to set the right event number. I have no clue what's different than my other configs tbh, just the lack of other events (though I'm confident I have them on separate devices anyway so...very mysterious still). ` ;Put this config in a "name.cfg" file. ;After installing Midi Monster, run with: ;$ midimonster path/to/name.cfg [evdev in] device = /dev/input/event?? ;run "evtest" with no args to find your keyboard's event number [evdev out] exclusive = 0 output = Mouse2 Test [map] in.EV_KEY.KEY_Q > out.EV_KEY.BTN_MIDDLE `

YimingWu commented

2023-06-30 16:40:52 +02:00

Hi! So now you managed to make it work? Nice!

In my experience, I have remapped keys from two physical devices as ctrl and shift, and they do not seem to work well with many programs I tested. So for now try to keep "keyboard key" and "mouse button" in their own category, and "button" for some reason needs to be on the pointer device for a lot of program to work correctly.

Also keep in mind if you have a regular keyboard wanting to do key remapping in a midi fashion, keep in mind that a regular keyboard typically never supports pressing more than maybe 3 or 4 keys physically except for modifier keys due to the nature of its key scanning layout, so that could also be a factor affecting your use.

Will close the issue since the problem has been resolved, but feel free to add additional information.

Hi! So now you managed to make it work? Nice! In my experience, I have remapped keys from two physical devices as ctrl and shift, and they do not seem to work well with many programs I tested. So for now try to keep "keyboard key" and "mouse button" in their own category, and "button" for some reason needs to be on the pointer device for a lot of program to work correctly. Also keep in mind if you have a regular keyboard wanting to do key remapping in a midi fashion, keep in mind that a regular keyboard typically never supports pressing more than maybe 3 or 4 keys physically except for modifier keys due to the nature of its key scanning layout, so that could also be a factor affecting your use. Will close the issue since the problem has been resolved, but feel free to add additional information.

YimingWu closed this issue

2023-06-30 16:40:54 +02:00

Blender Bot added

and removed

labels 2023-06-30 16:40:56 +02:00

vassiliscooper commented

2023-06-30 17:14:17 +02:00

Ok I figured out the specific cause, I also replicated the exact same issue in Krita and solved it in the same way.

It's weird, but apparently, Blender doesn't like it when the middle click is on a virtual pointer device...Yeah, I'm not kidding. The solution is actually to put middle click on a qwerty device instead (as in no mouse axes enabled).

More detail:
From my testing, in order for xinput to recognize a device as a pointer, it requires BOTH REL_X & REL_Y axes to be enabled, AS WELL AS one of BTN_LEFT or BTN_RIGHT. If the axes are missing, it's not categorized as a pointer, if neither the left or right buttons are enabled, it's not detected at all.

So, BTN_MIDDLE is unnecessary for virtual pointer device creation. In fact, the condition that makes it break IS when it's enabled on a REL_X + REL_Y having device. THis is extremely weird because any other event I've tried (basically the whole keyboard) can work just fine, even if it's on a pointer device.

I don't know what Blender and Krita have in common when it comes to handling user input, but something's not right on their side of the equation, because as I said initially the rest of the OS receives all those middle clicks perfectly fine.

I don't think requiring that middle clicks be placed on a non-pointer virtual device, while accepting them from pointer physical devices is intended behavior, and it still breaks a bunch of otherwise valid setups where device creation is not user customizable, so there's no external fix. I still think this is buggy behavior.

Ok I figured out the specific cause, I also replicated the exact same issue in Krita and solved it in the same way. It's weird, but apparently, Blender doesn't like it when the middle click is on a virtual pointer device...Yeah, I'm not kidding. The solution is actually to put middle click on a qwerty device instead (as in no mouse axes enabled). More detail: From my testing, in order for xinput to recognize a device as a pointer, it requires BOTH REL_X & REL_Y axes to be enabled, AS WELL AS one of BTN_LEFT or BTN_RIGHT. If the axes are missing, it's not categorized as a pointer, if neither the left or right buttons are enabled, it's not detected at all. So, BTN_MIDDLE is unnecessary for virtual pointer device creation. In fact, the condition that makes it break IS when it's enabled on a REL_X + REL_Y having device. THis is extremely weird because any other event I've tried (basically the whole keyboard) can work just fine, even if it's on a pointer device. I don't know what Blender and Krita have in common when it comes to handling user input, but something's not right on their side of the equation, because as I said initially the rest of the OS receives all those middle clicks perfectly fine. I don't think requiring that middle clicks be placed on a non-pointer virtual device, while accepting them from pointer physical devices is intended behavior, and it still breaks a bunch of otherwise valid setups where device creation is not user customizable, so there's no external fix. I still think this is buggy behavior.

👍 1

YimingWu commented

2023-07-02 17:32:56 +02:00

@vassiliscooper Thanks for investigating it further and providing feedback!

I believe this is somehow related to how the program gets the event. In some programs which uses e.g. pygtk, input from keyboard 2 might clear the previous states of keyboard 1, or they might not want to register BTN_LEFT up from any other devices if you have pressed it from one device. QT programs also work differently, they always want to treat pen device as touch input and will ignore pen-up in some ways. I'm not certain on what the cause is, but I suspect this might just be one of those X11/linux quirks we have to deal with.

@vassiliscooper Thanks for investigating it further and providing feedback! I believe this is somehow related to how the program gets the event. In some programs which uses e.g. `pygtk`, input from keyboard 2 might clear the previous states of keyboard 1, or they might not want to register BTN_LEFT `up` from any other devices if you have pressed it from one device. QT programs also work differently, they always want to treat pen device as touch input and will ignore pen-up in some ways. I'm not certain on what the cause is, but I suspect this might just be one of those X11/linux quirks we have to deal with.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Uinput middle click not recognized #109506