When reverse-scrolling for touchpad is on, the intended effect is "natural scrolling" but this also inverts the already "natural" scroll direction of the window shade feature. Window shade should account for natural scrolling setting so that it can remain "natural" when touchpad's natural-scrolling setting is active. Affects: Xorg/Wayland. Also reproduced with synaptics driver. I use libinput To reproduce: * Go to System Settings > Window Management > Window Behavior > Titlebar Actions * Set shade/unshade to "wheel event", and apply * Go to System Settings > Input Devices > Touchpad > scrolling (tab) * set "reverse scrolling" on, apply changes Current behavior: touchpad scroll event (which I guess should be renamed, but I'll create an issue for that) in the up direction causes unshade, and vice-versa for shade. Expected Behavior: Touchpad scroll event in up direction causes window to shade, and down event to unshade.
On X11 this is unfixable. On Wayland I cannot imagine how that could not work. Did you really test on Wayland?
I haven't used wayland in a while - multi-screen is not reliable enough for work yet. I remember this issue being the case back in 5.10ish. I will take some time to re-test and update accordingly here.
is it truly "unfixable" in X, or is it just not something worth doing? Can you provide some color on why it's unfixable?
Yes it is unfixable. This would require adding support for xinput scroll events. KWin doesn't support them yet and this would require a major refactoring in KWin to make use of it. Given that we feature froze X11 this is unfixable.
I logged into a wayland session to test. Not sure if other factors (multimonitor and different scaling sizes are pretty wonky in my hardware/environment combination) The scroll to shade/unshade windows is completely broken - it doesn't actually shade/unshade at all now. I do recall it working the same incorrect way as on X, though that's based on memory. Actual fact right now is that it did not work at all. I verified in system settings after it failed to shade, and the setting is active for window shading on mouse scroll.
(In reply to Martin Flöser from comment #4) > Yes it is unfixable. This would require adding support for xinput scroll > events. KWin doesn't support them yet and this would require a major > refactoring in KWin to make use of it. Given that we feature froze X11 this > is unfixable. I appreciate your response. In the interest of transparency, I think it is more accurate to say "this is something we don't want to fix" rather than "unfixable." It's not a challenge to your decision - you own that. In fact I respect it, given all the work to be done, a minor nag about scroll direction is nothing. Maybe it's just me, but I'd rather hear "I acknowledge bug, but we're not going to fix this because $Strategy" than "I label this unfixable and submit no rationale behind my statement." Anyway, I'm going to reword this bug to be wayland specific, and to address the fact that it simply doesn't work.
I just realized I can't edit original comment. I changed Bug summary to reflect this is a wayland problem where it doesn't work at all. To reproduce: * Go to In System Settings > Window Management > Window Behavior > titlebar Actions * Set shade/unshade to "Wheel event" and apply Current behavior: Window shade effect does not occur when mouse wheel/touchpad scroll is done over the title bar. Expected behavior: Window should shade/unshade based on scroll up/down event.
On Wayland shade is only supported for X11 windows, not for Wayland windows. The mouse wheel functionality in general works.
I'm setting this bug to wontfix as: a) on X11 there is nothing we can do, we won't add support for natural scrolling b) on Wayland this works, just shade is not supported. This is a known limitation currently, but completely unrelated to this bug report