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

Mouse move pointer does not reflect when drag will move - eglfs

    XMLWordPrintable

Details

    • Linux/Yocto, Linux/Other display system, webOS

    Description

      I'm trying to use Qt 6 with eglfs (QPA) component in Linux and when I build and run test app and move mouse, mouse move pointer doesn't reflect.

       

      It happens if mouse move on eglfs component, if I tested qml like this:

      import QtQuick 2.12
      import QtQuick.Window 2.12

      Window {
      width: 640
      height: 480
      visible: true

      title: qsTr("MouseArea")

      Rectangle {
      width: 500; height: 500
      color: "green"
      MouseArea

      { anchors.fill: parent; onPressed: (mouse)=>

      { parent.color = 'blue'; console.warn("mouse press btn : " + mouse.button); }

      onPositionChanged: (mouse)=> { parent.color = 'yellow'; console.warn("mouse move y : " + mouse.y + ", btn : " + mouse.button); }
      }
      }
      }

       

      I tested it on eglfs with above test app and the mouse move event is no longer responding. The mouse move events no longer appear when dragging in the MouseArea when viewing logs. When I tested, Qt::LeftButton appears when mouse moves through eglfs, but Qt::NoButton appears to come up through QPA rather than eglfs.

       

       

      If looking at the commit message as shown below, I can see that drag is set to "QEventPoint::State::Updated". In order for the state to be updated, it have to come up as a Qt::NoButton.

      When dragging (with mouse), is the assumption that it comes up as a Qt::NoButton correct?

       

      commit 5ca5dfa89e05c6deda6cd9282cd505eb324228cd
      Author: Shawn Rutledge <shawn.rutledge@qt.io>
      Date:   Wed Jul 15 10:47:55 2020 +0200
       
          Set QEventPoint::state properly in QSinglePointEvent    
      
          State was Unknown by default, and that is OK in widgets so far, because
          widgets pay attention to the event type, not QEventPoint::state().
          But Qt Quick cares about that, because QEventPoint turns into
          QQuickEventPoint, in which state() has long been important, due to
          the semi-unified handling of mouse and touch events.    If it was not a button that caused the event, state is Updated (the
          mouse is hovering or dragging, or it's an enter event, wheel event etc.)
          If more buttons are now held than before, state is Pressed.
          If fewer buttons are now held than before, state is Released.
          Amends 4e400369c08db251cd489fec1229398c224d02b4
          Change-Id: I926d268982449e46e7ca713c4a6ee2014c28c645
          Reviewed-by: Fabian Kosmale <fabian.kosmale@qt.io>
      
      diff --git a/src/gui/kernel/qevent.cpp 
      b/src/gui/kernel/qevent.cpp
      index c77a6b23c6..0284dc2098 100644
      --- a/src/gui/kernel/qevent.cpp
      +++ b/src/gui/kernel/qevent.cpp
      @@ -350,6 +350,12 @@ QSinglePointEvent::QSinglePointEvent(QEvent::Type type, const QPointingDevice *d
             m_reserved(0)
       {
           QMutableEventPoint &mut = QMutableEventPoint::from(m_point);
      +    if (button == Qt::NoButton)
      +        mut.setState(QEventPoint::State::Updated); // stationary only happens with touch events, not single-point events
      +    else if ((button | buttons) == buttons)
      +        mut.setState(QEventPoint::State::Pressed);
      +    else
      +        mut.setState(QEventPoint::State::Released);
           mut.setPosition(localPos);
           mut.setScenePosition(scenePos);
           mut.setGlobalPosition(globalPos);
      

       

       

      Attachments

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

        Activity

          People

            srutledg Shawn Rutledge
            cathy.park YoungSun Park
            Votes:
            0 Vote for this issue
            Watchers:
            7 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes