Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. Qt 6
  4. Crash on EGLFS Platform After Qt 6.5 Migration During Instant Resume(App Background/Foreground Transition)
Forum Updated to NodeBB v4.3 + New Features

Crash on EGLFS Platform After Qt 6.5 Migration During Instant Resume(App Background/Foreground Transition)

Scheduled Pinned Locked Moved Unsolved Qt 6
10 Posts 2 Posters 1.1k Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • _ Offline
    _ Offline
    __K2403__
    wrote on last edited by
    #1

    Hi all,

    We're encountering a crash after migrating our Qt-based application from Qt 5.15.1 to Qt 6.5, specifically when using the EGLFS platform on an ARM device.

    Background:
    We have implemented a feature called "instant resume". The idea is to simulate a seamless background-to-foreground transition by hiding the application and bringing it back later—providing a smooth resume experience.

    Due to the EGLFS platform limitation of supporting only a single surface, we cannot keep the surface alive when the app goes to the background. As a result, we are required to release the surface and related resources, which means we must call QWindow::close() instead of QWindow::hide() when putting the app in the background, and QWindow::show() (or re-create the window) when bringing it back to the foreground.

    To support this, we implemented a custom EGLFS hook that overrides the default destroyNativeWindow() behavior:

    #include "private/qeglfshooks_p.h"
    #include <stdio.h>

    QT_BEGIN_NAMESPACE

    class QEglFSCustomHooks : public QEglFSHooks
    {
    public:
    void destroyNativeWindow(EGLNativeWindowType window) override;
    };

    void QEglFSCustomHooks::destroyNativeWindow(EGLNativeWindowType window)
    {
    Q_UNUSED(window);
    eglTerminate(EGL_NO_DISPLAY);
    }

    QEglFSCustomHooks eglFSCustomHooks;
    QEglFSHooks *platformHooks = &eglFSCustomHooks;

    QT_END_NAMESPACE
    With this setup, everything worked fine on Qt 5.15.1.

    Issue After Migration to Qt 6.5:
    After upgrading to Qt 6.5, the app crashes when trying to resume (bring the app back to the foreground). Here's the backtrace:

    Searching frame 0 (FP=b55afd7c, PC=4201ff60)
    Failed to find prior stack frame; terminating backtrace.
    /usr/lib/libmali.so41db0000[4201ff60]

    And this message appears in the GPU logs:

    [rtk][gpu] eglp_window_surface_specific_initialization: use the same native window descriptor to create egl surface!

    Questions:
    Is overriding destroyNativeWindow() still supported in Qt 6.5, or is there a better/recommended way to release surface resources for EGLFS?

    How should we safely implement "instant resume" behavior under EGLFS in Qt 6.5?

    Any help, insights, or directions would be greatly appreciated!

    1 Reply Last reply
    0
    • _ Offline
      _ Offline
      __K2403__
      wrote last edited by
      #2

      @SGaist can you please suggest something ?

      1 Reply Last reply
      0
      • SGaistS Offline
        SGaistS Offline
        SGaist
        Lifetime Qt Champion
        wrote last edited by
        #3

        Hi,

        It's been a very long time since I looked at these part. Did you already took a look at the QRhi ?

        This was one of the big changes and I wonder if the changes related may have created a regression of your use case.

        Interested in AI ? www.idiap.ch
        Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

        1 Reply Last reply
        0
        • _ Offline
          _ Offline
          __K2403__
          wrote last edited by
          #4

          @SGaist
          As suggested i will start reviewing the QRhi classes, but I wanted to share more specific observations around a crash I’m encountering.

          The application crashes during the call to(inside qeglfswindow.cpp resetSurface call):
          eglCreateWindowSurface(display, m_config, m_window, nullptr);

          From the GPU logs, it appears the driver expects the same native window descriptor to be reused when creating an EGL surface.

          Here's a snippet from the relevant method:

          void QEglFSWindow::resetSurface()
          {
          EGLDisplay display = screen()->display();
          if (eglInitialize(display, nullptr, nullptr) != EGL_TRUE) {
          qCritical() << "eglInitialize failed:" << eglGetError();
          return;
          }

          QSurfaceFormat platformFormat = qt_egl_device_integration()->surfaceFormatFor(window()->requestedFormat());
          
          m_config = QEglFSDeviceIntegration::chooseConfig(display, platformFormat);
          m_format = q_glFormatFromConfig(display, m_config, platformFormat);
          
          const QSize surfaceSize = screen()->rawGeometry().size();
          m_window = qt_egl_device_integration()->createNativeWindow(this, surfaceSize, m_format);
          m_surface = eglCreateWindowSurface(display, m_config, m_window, nullptr);
          

          }
          The problem is that QEglFSDeviceIntegration::createNativeWindow() is always returning 0 because of the default. Interestingly, this works on some devices(with mali G31 driver) but crashes on others (other Mali drivers)—, based on logs like:

          [rtk][gpu] eglp_window_surface_specific_initialization: use the same native window descriptor to create egl surface!
          This leads me to believe the crash may be due to the creation of a new native window when the driver expects the same one to be reused.

          I’ve looked into custom implementations of createNativeWindow(), including references from eglfs_mali, but haven’t been able to get it working reliably.

          How can I properly override or provide a custom implementation of QEglFSDeviceIntegration::createNativeWindow() for mali devices?

          1 Reply Last reply
          0
          • SGaistS Offline
            SGaistS Offline
            SGaist
            Lifetime Qt Champion
            wrote last edited by
            #5

            If you want to keep things clean, I think you would need to create your own platform plugin that derives from the eglfs implementation.

            Interested in AI ? www.idiap.ch
            Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

            1 Reply Last reply
            0
            • _ Offline
              _ Offline
              __K2403__
              wrote last edited by
              #6

              @SGaist Okay, I'll try creating the custom platform plugin and check. I believe there are some references available within the Qt EGLFS plugins themselves..Thank you so much for replying back ...

              1 Reply Last reply
              0
              • SGaistS Offline
                SGaistS Offline
                SGaist
                Lifetime Qt Champion
                wrote last edited by
                #7

                You are likely already building Qt yourself so as a first step, you could simply modify the original plug-in to get the behavior you need.

                Interested in AI ? www.idiap.ch
                Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                1 Reply Last reply
                0
                • _ Offline
                  _ Offline
                  __K2403__
                  wrote last edited by
                  #8

                  @SGaist you mean modify the QEglFSDeviceIntegration creatnativewindow method itself instead of creating a custom plugin

                  SGaistS 1 Reply Last reply
                  0
                  • _ __K2403__

                    @SGaist you mean modify the QEglFSDeviceIntegration creatnativewindow method itself instead of creating a custom plugin

                    SGaistS Offline
                    SGaistS Offline
                    SGaist
                    Lifetime Qt Champion
                    wrote last edited by
                    #9

                    @__K2403__ yes.
                    That way you avoid starting by inheriting private classes. It's doable but I think that starting your changes first there will be easier. Then when you achieved what you wanted, you can move to your own subclass knowing that things are working as you want.

                    Note that your work might be worth submitting for integration as well since it used to work.

                    Interested in AI ? www.idiap.ch
                    Please read the Qt Code of Conduct - https://forum.qt.io/topic/113070/qt-code-of-conduct

                    1 Reply Last reply
                    0
                    • _ Offline
                      _ Offline
                      __K2403__
                      wrote last edited by
                      #10

                      @SGaist sure will do that ...

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved