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

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

    XMLWordPrintable

Details

    • Bug
    • Resolution: Done
    • P2: Important
    • 5.15.1
    • 5.15
    • None
    • Arch Linux
    • Linux/Other display system
    • 30be6c41d5bb8ff4f42dd7ac26a763444be71c5a (qt/qtbase/dev) 0d4b67a95bae32d6eb4b9f8ff768f6449e9b2b2b (qt/qtbase/5.15)

    Description

      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.

      Attachments

        Issue Links

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

          Activity

            People

              srutledg Shawn Rutledge
              srutledg Shawn Rutledge
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There is 1 open Gerrit change