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

QQuickStyle "Material" draws the ripple effect in the wrong place, always at the top left corner on screen with QT_QPA_BECKEND=software

    XMLWordPrintable

Details

    • Bug
    • Resolution: Duplicate
    • P2: Important
    • None
    • 5.14.1
    • None
    • ARM 32-bit GNU/Linux Kernel 4.4.32
    • Other

    Description

      I have observed the issue whem running a QML application on embedded target with Linux FB backend.
      What I have observed is when I was running my application on Ubuntu 24.04 desktop working fine and when I run it on my embeddedd HMI the issue appears.
      Then I found that  if I set the environment 

      QT_QUICK_BACKEND=software

      the issue appears even on ubuntu desktop also.

      I am using material style with QML components and whenever I am using QML component which uses RippleEffect, RoundedElevationEffect than there is an issue in the appearance of the control.
      Currently I have found issue in
      Button - Issue in ripple and highlight posiion which is showing at top left corner of the screen

      ComboBox - Issue in background of the dropdown(popup which is opened on click) which appears transparent and highlight of text field option

      Dialog - issue in background and highlight

      Popup - issue in background and highlight

       

      I am using Qt6.8.1

      Target is ARM-32bit Embedded Linux without any graphics hardware support

       

       

       

      Older issue

      When using QQuickStyle "Material", the ripple effect is displayed incorrectly when running the application using the -platform wayland flag on an embedded machine running ARM 32-bit using a GNU/Linux Kernel 4.4.32.x.

      This issue occurs when clicking or pressing items on various locations across the application. No matter what, the ripple effect will display at the very top-left of the screen and will be the shape of a giant circle. After the touch event or mouse event has ended, the circle left behind by the ripple will remain visible as well. This issue happens with both touch presses and mouse clicks.

      It should be noted that the touch event and mouse events seems to be properly passed; the ripple effect is just drawing in the wrong location.

      By running using the -platform eglfs flag, this does not occur. It seems to be exclusive to running as a Wayland client. I have tried using different wayland shell protocols such as ivi, xdg, and wl, but the issue remains the same.

      By switching the QQuickStyle from "Material" to "Universal", the animations for pressing buttons do work, but this is because (as far as I know), the Universal style does not use Ripple.

      Finally, I have tested using Linux on Ubuntu 18.04 LTS and it does work fine under there, even when running the application as a Wayland client under a QWayland compositor. Both the application and the compositor were the same ones I am testing with under the ARM platform. The ripple effect is drawn correctly on the right place and is the right size for the object interacted with.

      To reproduce, use wayland/minimal-qml as the compositor and use the quickcontrols2/texteditor example as the application with the -platform wayland flag set. Press the buttons and you can see the Ripples being drawn in the top-left corner as a large circle.

      The Qt 5.14.1 cross-compiled for my ARM machine is using the eglfs-kms integration if that is relevant.

      Please let me know if there is any additional information I can provide!

      Attachments

        Issue Links

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

          Activity

            People

              qt.team.quick.subscriptions Qt Quick and Widgets Team
              neerajusadadiya Neeraj Usadadiya
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

                Created:
                Updated:
                Resolved:

                Gerrit Reviews

                  There are no open Gerrit changes