Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-83973

wayland multi-screen compositor example has redundant cursors with multiple eglfs screens



    • Type: Bug
    • Status: Closed
    • Priority: P2: Important
    • Resolution: Done
    • Affects Version/s: 5.15
    • Fix Version/s: 5.15.1
    • Labels:
    • Environment:
      Arch Linux
    • Platform/s:
      Linux/Other display system
    • Commits:
      30be6c41d5bb8ff4f42dd7ac26a763444be71c5a (qt/qtbase/dev) 0d4b67a95bae32d6eb4b9f8ff768f6449e9b2b2b (qt/qtbase/5.15)


      This happens when running examples/wayland/multi-screen with two physical monitors on eglfs, with the following JSON configuration:

        "device": "/dev/dri/card0",
        "virtualDesktopLayout": "vertical",
        "hwcursor": true,
        "pbuffers": true,
        "outputs": [
            "name": "eDP1",
            "mode": "2880x1920",
            "primary": true
            "name": "DP1",
            "mode": "3840x2160",
            "virtualPos": "0, -2160"

      If you have two screens, you get two cursors moving together. Until you move the mouse over a window that sets a cursor, you might not see a cursor at all. But if you move over a Konsole window, for example, at least one of the cursors changes to i-beam and tends to gets stuck that way. If you move to the edge of a window to resize it, sometimes one cursor changes to the resize cursor and the other remains an i-beam, so you see them superimposed. (In addition you could get one more cursor, a white arrow cursor; but that can be disabled by setting QT_QPA_EGLFS_HIDECURSOR. WaylandMouseTracker.windowSystemCursorEnabled doesn't seem to affect it.) If you move the cursor from one screen to the other, the cursor on the first screen doesn't get hidden but stays in the same place until you move back to that screen again.

      QWaylandMouseTracker::hoverMoveEvent() doesn't set the hovered state, but hoverEnterEvent/hoverLeaveEvent aren't happening, so that's why both cursors stay visible. A QHoverEvent only has local pos, not global pos, so it appears difficult to make the decision in hoverMoveEvent() about whether the cursor should still be visible or not. But perhaps the bug is that the enter/leave should really happen.

      Confirmed that in 5.14 they do happen.


          Issue Links

          No reviews matched the request. Check your Options in the drop-down menu of this sections header.



              srutledg Shawn Rutledge
              srutledg Shawn Rutledge
              0 Vote for this issue
              2 Start watching this issue



                  Gerrit Reviews

                  There is 1 open Gerrit change