Skip to content
Snippets Groups Projects

qt: assume touchpad wheel events are inverted if invertedness is not reported

1 unresolved thread

WheelToVLCConverter is not used for scrolling, so we have to handle inversion. This was already done in 1ba2a2db (!6610 (merged)), but unfortunately not all platform (plugins) report invertedness.

According to my knowledge, Mac and Wayland platform plugins report, while Xcb and Windows/Direct2D do not report.

Usually touchpad scrolling direction is inverted, which may be the source of events in this class, so it makes more sense to assume the wheel events are inverted by default.

Request review @chub.

Edited by Fatih Uzunoğlu

Merge request reports

Loading
Loading

Activity

Filter activity
  • Approvals
  • Assignees & reviewers
  • Comments (from bots)
  • Comments (from users)
  • Commits & branches
  • Edits
  • Labels
  • Lock status
  • Mentions
  • Merge request status
  • Tracking
  • Fatih Uzunoğlu changed the description

    changed the description

  • added 1 commit

    • 20d84013 - qt: forward the remaining of `QQuickWheelEvent` properties in `WheelToVLCConverter`

    Compare with previous version

    • Author Reporter

      Although this works fine on X11, it is still not enough for Windows because device type is reported as QInputDevice::DeviceType::Mouse in my case on Windows 11 with precision touchpad.

      I'm not sure what can be done, maybe for Windows we need to invert all fractional events (angle delta not multiple of 120). The concern with that is non-standard mouse that provide fractional delta for wheel events and not inverted by default.

    • Author Reporter

      According to https://github.com/qt/qtbase/blob/a5f80b4732d33dd36414a6ffbd49a9efc7c87a0a/src/plugins/platforms/windows/qwindowspointerhandler.cpp#L67, Qt does not handle touch pad (pointer) messages, so I assume that Windows sends a mouse wheel message afterward because of that.

      I'm not sure how much it makes sense to handle pointer messages ourselves in the application specifically for Windows. I would rather invert all events where delta is high precision / fractional on Windows, what do you think @chub?

    • On windows, there are indeed two types of messages for mouse events:

      • QtWindows::NonClientMouseEvent
      • QtWindows::NonClientPointerEvent

      handled here respectively by translateMouseEvent and translatePointerEvent

      Mouse events are indeed reported as never inverted (wheel event use the default inverted value, which is false)

      are inverted if invertedness is not reported

      are you sure it needs to be inverted? the touchpad seems to behave the same way as windows other applications (both the volume and list/grid scrolling) As far as I know, there is no way to invert scroll direction from Windows settings

    • note on XCB, mouse direction is not reported as well (here), but I see no issue with this, the current behavior is the same across application (both how volume and flickables are handled)

      Note that Kde on X11 allows to invert the scroll direction on both touch and mouse, which gives the expected behaviors

      It looks like your assumptions on what should be inverted is inverted ;-)

    • Author Reporter

      are you sure it needs to be inverted?

      It needs to be inverted, because it is inverted by default due to natural scrolling, and here we don't intend to use it for scrolling.

      the touchpad seems to behave the same way as windows other applications (both the volume and list/grid scrolling)

      I think that is because most applications do not handle pointer events, but rather rely on mouse wheel events. That does not necessarily mean that we should do the same.

      the current behavior is the same across application (both how volume and flickables are handled)

      In flickable case, it is scrolling but in this case it should not be considered scrolling so we should in my opinion invert if the event is inverted.

      "Scrolling" down to increase volume or left to seek forward is really counter-intuitive in my opinion.

      As far as I know, there is no way to invert scroll direction from Windows settings

      On Windows 11, at least with precision touchpad, there is a setting to change the direction. The default is inverted (first entry). Note how it is not advertised as "inverted".

      note on XCB, mouse direction is not reported as well

      In my case it is reported, have you seen the check above (https://github.com/qt/qtbase/blob/a10acaca0887541207ad5607680d7864d317cf4b/src/plugins/platforms/xcb/qxcbwindow.cpp#L1954) connection()->isAtLeastXI21(), maybe it is about that?

      but I see no issue with this, the current behavior is the same across application (both how volume and flickables are handled

      This is really not good in my opinion, in flickable case it is scrolling, but it is not scrolling for volume.

      Note that Kde on X11 allows to invert the scroll direction on both touch and mouse, which gives the expected behaviors

      That is usually advertised as "Natural Scrolling" on Linux. I'm not sure if it comes on by default but as the name suggests it is rather for scrolling (not for adjust the sliders, for example).

    • Author Reporter

      In my case it is reported, have you seen the check above

      I mean the device here, not invertedness (that is why windows and xcb are blacklisted in this merge request as they don't report invertedness). This makes it possible to assume that if the device is touchpad, it is inverted by default if invertedness is not reported.

    • "Scrolling" down to increase volume or left to seek forward is really counter-intuitive in my opinion

      that's people choice, other volume widgets in other applications will behave this way. If we're the only application that doesn't respect the user choice this will be very annoying. note that in VLC, wheel direction in detached windows do behave like this too

      In my case it is reported, have you seen the check above (https://github.com/qt/qtbase/blob/a10acaca0887541207ad5607680d7864d317cf4b/src/plugins/platforms/xcb/qxcbwindow.cpp#L1954) connection()->isAtLeastXI21(), maybe it is about that?

      With XInput2 wheel event is handled here but direction is not provided as well, I think it's changed on server side

    • Author Reporter

      that's people choice

      I can't agree with that, both as a user and a developer.

      The setting is advertised for scrolling. Adjusting the volume is not scrolling, so it should always "scrolling" up increase the volume and vice versa.

      The people choice is for scrolling and I agree that we should respect it, that's why I opened !6665 (merged).

    • Please register or sign in to reply
  • Steve Lhomme changed milestone to %4.0

    changed milestone to %4.0

  • Fatih Uzunoğlu mentioned in merge request !6665 (merged)

    mentioned in merge request !6665 (merged)

Please register or sign in to reply
Loading