Important: Please read the Qt Code of Conduct -

QApplicationStateChanged Signal Not Emitted When Running With EGLFS Platform

  • Hello,

    I have a QApplication object and I have connected its QApplicationStateChanged signal to a slot in a custom object. In the slot, I test on the Qt::ApplicationState parameter and, if the QApplication is in the ApplicationReady state I begin drawing objects to the window.
    This works fine when run with the default plugin (I am assuming XCB but not sure how to confirm that) but when run with -platform eglfs the signal doesn't seem to be emitted. Or, perhaps more accurately, the connected slot is not called.

    I can verify that the application state changes by querying and printing the QApplication::ApplicationState() at different times - the state certainly does change from 2 (ApplicationInactive) to 4 (ApplicationReady) but the signal is never emitted.

    I can emit the signal myself before the call to app.exec() but this results in drawing being done before the window is initialised and positioning, scaling etc. doesn't behave as it should. I can create a timer and connect the QTimer::timeout() signal to a slot which emits the QApplication::ApplicationStateChanged signal with the correct state, but this feels a bit of a nasty hack around it.

    Is there something I'm missing?

    I'm developing in Debian Jessie 64bit and Qt 5.9. Also running on an Odroid XU4 but the described behaviour is evident in both environments

    In case it's of benefit, I can provide some example code:


    int main(int argc, char *argv[])
       QApplication app(argc, argv);
        std::cout << "Application state: " << app.applicationState();//Output here is: Application state: 2
       // engine, context, window etc. creation
        LabelUpdater* myLabelUpdater = new LabelUpdater(&engine, window, mPrint_info, &app);//App only passed here to be used in timer slot - something I want to avoid!
    QThread::connect(&app, SIGNAL(applicationStateChanged(Qt::ApplicationState )), myLabelUpdater, SLOT(app_state(Qt::ApplicationState )));//Connect application's StateChanged() signal to handler in LabelUpdater. Using this mechanism, we can draw elements on the view when the window has initialised. app_state is NOT the slot which emits app::applicationStateChanged. This is done in temp() and should be avoided. This connection works with the default platform but doesn't seem to work in eglfs.
    QTimer* myTimer = new QTimer();
        QThread::connect(myTimer, SIGNAL(timeout()), myLabelUpdater, SLOT(temp()));
        myTimer->start(); //Inside temp() is an emit->app->applicationStateChanged(Qt::ApplicationReady). This is a (hopefully) temporary workaround to get drawing working properly in EGLFS.
    rc = app.exec();
    delete component;
    return rc;


    void LabelUpdater::app_state(Qt::ApplicationState state)//This works well in default platform
        if(state == Qt::ApplicationState::ApplicationActive)
                    for(int sc = 0; sc < platformSensorCount; sc++)
                        Sensor s = platformSensorList[sc];
                    for(int sc = 0; sc < mySensorList.size(); sc++)
                        Sensor s = mySensorList[sc];
                        this->add_srf_by_percent(s.sensorX, s.sensorY, s.sensorOrientation, s.bbbHostId, s.sensorNum);
                this->sensors_set = true;
    void LabelUpdater::temp()//When called from the QTimer slot after 1second, this allows drawing to be performed as expected running in EGLFS
        std::cout << "[LabelUpdater::temp()]: In temp();" << std::endl;
        emit this->app->applicationStateChanged(Qt::ApplicationActive);

  • Is anyone able to hint at why the QApplicationStateChanged signal is not emitted when using the EGLFS platform?

    Using a single shot timer to trigger a slot which contains a loop querying the application for its state provides the required functionality as a workaround, but is this the way it should be done?

  • Lifetime Qt Champion

    Hi and welcome to devnet,

    From a quick look at the platform plugin sources, it seems that this one doesn't support application state but I don't know whether there should be some sort of emulation taking place in this case.

    That's a question you should ask on the interest mailing list. You'll find there Qt's developers/maintainers. This forum is more user oriented.

Log in to reply