Description of problem: Fedora 26/blender-2.78c-4 on Thinkpad T520 Steps to reproduce: Start blender with the default scene and default settings. In the default scene press and hold the middle mouse button of the three mouse buttons below the laptop's space bar and move the TrackPoint in any direction. Orbiting won't work, that is moving left or right will not have any effect while moving up and down will zoom in and out - but orbiting is expected. The T520 also has a trackpad with two further buttons below it. While the middle mouse button emulations of both the Gnome desktop and blender are disabled there still seems to be another type of middle mouse button emulation enabled, that is pressing both thee buttons (the timing is a bit hard to hit) and using either the TrackPoint or the touchpad will orbit as expected. An external USB mouse with scroll wheel will also work as expected. Neither the Gnome's nor Blender's middle mouse button emulation seem to make a difference, in fact I can't seem to get it to work with the Trackpoint's three buttons. Another blender user who is on Fedora 25 told me on IRC he was seeing the same behaviour. Version-Release number of selected component (if applicable): blender-2.78c-4 How reproducible: Always. Additional info: I've tried alternative Fedora 26 desktops, that is Gnome, Gnome Classic, Gnome on Xorg, Openbox, Plasma and Xfce, all with the same result. I installed the blender versions from Fedora 23, 24 and 25 along with their dependencies into a Fedora 26 system; all these older versions are showing the same behaviour so it would seem one of the other software components may be to blame. I tried fresh user accounts to make sure none of the old Gnome settings or other dot-files interfears; that didn't help either.
I have what I think is the same problem, though using camera panning in Kerbal Space Program instead. Testing from a text VTY with "evtest" shows seperate events on press and release for all buttons, including the middle trackpoint button. But testing with "xev" in a running Xorg session only fires events on release (though both press and release are then logged) when using the middle mouse button. So it seems like the kernel does things right, but somewhere on the way to X something stops working. I have only today upgraded to Fedora 26, so I don't know when the problem appeared. I have not seen the problem with Fedora 25. While searching I stumbled upon bug 1482640, but I have no idea it it's related. How does one debug further on this? Specifically whatever is between what evtest reads from (kernel?) and what xev reads from (Xorg?). (And this is like _super_ critical, not being able to play Kerbal Space Program to its full extent is a big problem. ;-])
Hello(In reply to Ralf Baechle from comment #0) > Description of problem: > > Fedora 26/blender-2.78c-4 on Thinkpad T520 > > Steps to reproduce: > Start blender with the default scene and default settings. In the default > scene press and hold the middle mouse button of the three mouse buttons > below the laptop's space bar and move the TrackPoint in any direction. > Orbiting won't work, that is moving left or right will not have any effect > while moving up and down will zoom in and out - but orbiting is expected. Hello Ralf, I just saw this report at the time of writing (I don't know why this report did not show up on my e-mail until now). What you faced seemed a issue related to Thinkpad as I am unable to reproduce on my laptop, an ASUS X550 running the latest stable Blender. Further research to Lenovo possibly releaved an issue with libinput: https://forums.lenovo.com/t5/Linux-Discussion/Thinkpad-X1-Carbon-2017-Gen5-Touchpad-Issue-Linux/td-p/3620920/page/9 thus assigning the report to that component.
Lets change the title for better description of the problem.
I'm also on a Thinkpad, though a T530 (specifically model 24295ZG). So it's probably specific to Thinkpad. Agree that it's not Blender. And good thing to rename the bug, but I don't think it's emulation failing. Emulation (when using left+right lower mouse buttons, those that belong to the touchpad) actually works, whereas the physical middle mouse button (upper buttons, between the spacebar and the touchpad) does not. Maybe it could be called "Middle mouse button fails on Thinpad T520/T530"? It tested installing "xorg-x11-drv-synaptics-legacy" and that does not seem to make a difference to this problem, though the touchpad does seem to handle a bit better. I have perused the Lenovo forum thread and it doesn't look like the same problem to me. In this case everything except the physical middle mouse button works, and the problems seems to be that the "press" event is held back until the button is released, at which point it arrives together with the "release" event. And this is seen with "xev"; testing with "evtest" from a text VTY shows events arriving as expected, "press" on button down and "release" on button up.
As per request, renaming the title.
fwiw, is's usually easy to figure out what libinput is doing by running 'sudo libinput debug-events' and then looking at the output. if I'm reading this correctly, a middle button press + move triggers a zoom, not an orbit. That's caused by the middle button scroll emulation that is enabled by default on the trackpoint devices, it converts middle down + movement to a wheel event equivalent. under X you can permanently disable this with an xorg.conf snippet that sets Option "ScrollMethod" "none" for that device. Or with xinput set-prop "device name" "libinput Scroll Method Enabled" 0 0 0, but that's not persistent. I don't think GNOME has a toggle for that yet.
Thanks for the pointers! At least for me it is not related to any kind of scrolling. In Kerbal Space Program the pointer behaves exactly like the middle mouse button was never pressed, until release, at which point it very very briefly acts as if pressed. I tried "libinput debug-events" and it seems like libinput actually knows when the "pressed" event arrives, but it doesn't print the event to the terminal before the relase event has arrived. So the timestamp relative from process start in third column displays the correct time, but the output line saying this doesn't come until later. The following is an example where I press the mousebuttons 1, 2, 3 in turn, first doing a short-ish click and afterwards holding each button for a few seconds (newlines inserted for readability): # unbuffer libinput debug-events --device=/dev/input/event6 | ts '[%Y-%m-%d %H:%M:%.S]' [2017-11-14 21:40:12.359188] -event6 DEVICE_ADDED TPPS/2 IBM TrackPoint seat0 default group1 cap:p left scroll-nat scroll-button [2017-11-14 21:40:14.064402] event6 POINTER_BUTTON +1.71s BTN_LEFT (272) pressed, seat count: 1 [2017-11-14 21:40:14.173700] event6 POINTER_BUTTON +1.82s BTN_LEFT (272) released, seat count: 0 [2017-11-14 21:40:14.848094] event6 POINTER_BUTTON +2.39s BTN_MIDDLE (274) pressed, seat count: 1 [2017-11-14 21:40:14.848271] event6 POINTER_BUTTON +2.50s BTN_MIDDLE (274) released, seat count: 0 [2017-11-14 21:40:15.502475] event6 POINTER_BUTTON +3.15s BTN_RIGHT (273) pressed, seat count: 1 [2017-11-14 21:40:15.591440] event6 POINTER_BUTTON +3.24s BTN_RIGHT (273) released, seat count: 0 [2017-11-14 21:40:18.858315] event6 POINTER_BUTTON +6.51s BTN_LEFT (272) pressed, seat count: 1 [2017-11-14 21:40:21.432588] event6 POINTER_BUTTON +9.08s BTN_LEFT (272) released, seat count: 0 [2017-11-14 21:40:25.972962] event6 POINTER_BUTTON +10.82s BTN_MIDDLE (274) pressed, seat count: 1 [2017-11-14 21:40:25.973145] event6 POINTER_BUTTON +13.62s BTN_MIDDLE (274) released, seat count: 0 [2017-11-14 21:40:28.991058] event6 POINTER_BUTTON +16.64s BTN_RIGHT (273) pressed, seat count: 1 [2017-11-14 21:40:32.251229] event6 POINTER_BUTTON +19.90s BTN_RIGHT (273) released, seat count: 0 As you can see there are pressed/released events at +10.82s and +13.62s respectively, but the output lines (per ts stamp) appear practically simultaneously. So I wonder, why does libinput seem to hold on to the "pressed" event for the middle mouse button? My guess is that this is what makes both Blender and Kerbal Space Program seem like the button isn't working.
Still sounds like the button scroll emulation. Basically: we don't know whether we can send a middle button event until we've seen some movemement (no event!) or the button was released without any movement (yay, send it!). What happens when you move the trackpoint? Do you see POINTER_AXIS events? If so, wheel emulation is the issue and you need to turn it off.
Ah, sorry, I didn't really give due attention to what you wrote. I usually never touch the trackpoint and only in the context of this problem have I found out that the buttons I use technically belong there. You are right, it's the scroll method. I do see POINTER_AXIS events on manipulating the trackpoint with middle mouse button pressed. (And POINTER_MOTION without.) After issuing "xinput set-prop 'TPPS/2 IBM TrackPoint' 'libinput Scroll Method Enabled' 0 0 0" everything works as I expect them to. So I guess that means it's not a bug as such. I assume that the current default setting was chosen for a reason. (A change from Fedora 25 I guess.) I can accept that, though I will argue that having this scroll emulation enabled by default is less than optimal. The problem presents itself in a way that makes it very hard for people like Ralf and me to figure out what the cause is. It just looks like a middle mouse button that doesn't work. On the other hand, maybe Blender and Kerbal Space Program are among only few applications caught in this. In that case one could argue that it was easier to update documentation related to those applications to describe the problem and work arounds. I am on purpose not clearing the needinfo flag since it's probably best if Ralf posts a comment saying whether his problem actually is the same as mine. I hope I haven't just hijacked the bug. :-)
I'm pretty sure we've had this behaviour since f22 or so, libinput chose this default very early. Basically: the use-cases for middle-click + drag are few and far in between and mostly limited to 3d applications like blender. The use-case of using those applications with a trackpoint instead of a mouse is even smaller. OTOH, the use-case of needing scrolling with a trackpoint is a comparatively common one. This is just a default, we have to pick one and we went with the more common case. It's one of the cases where we can't make everyone happy which is why we have a configuration option in libinput, even if it hasn't trickled down into the GUI configuration programs yet. I'm closing this bug, Ralf's problem is almost certainly the same and if it's not he can re-open it :)