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

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

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed
    • Priority: P2: Important
    • Resolution: Done
    • Affects Version/s: 5.15
    • Fix Version/s: 5.15.1
    • Labels:
      None
    • Environment:
      Arch Linux
    • Platform/s:
      Linux/Other display system
    • Commits:
      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

              Assignee:
              srutledg Shawn Rutledge
              Reporter:
              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