"qt.qpa.wayland: Wayland does not support QWindow::requestActivate()"

JoeCFD

My first Yocto project. The message shows up in fullscreen mode only.

import QtQuick          2.15
import QtQuick.Controls 2.15
import QtQuick.Window   2.15

ApplicationWindow
{
    id: appWindow 
    //width: 640 
    //height: 480     
    visibility: Window.FullScreen
    visible: true
    title: qsTr("Main Window") }
}

Qt version 5.15.13. Yocto distribution is the latest. Qt6 is not an option in my project.

Is this message critical? Checked here out and could not find a solution.

Googled a bit. The problem seems a Qt bug.

JonB

@JoeCFD
I know that Wayland (or the compositor or whatever Qt is using) does not allow "activate window". You see that message from Qt wyaland component when you try to do so. I don't know why it shows for you full screen. I'm surprised Wayland lets you go full screen, or even lets you do much that you want.

I know that under Wayland when you get this message (Qt 5.x) or when it no longer outputs (Qt 6.x). I found the behaviour is so bad that I could not use Qt Creator: on hitting a breakpoint or a faulting signal it can no longer come up front on top of the debugged application window, so you don't even know a breakpoint/signal has been hit. Which I regard as so bad for development that I have had to set QT_QPA_PLATOFROM=xcb for the benefit of all Qt programs.

If Wayland forbids this sort of thing I think that's terrible.

JoeCFD

@JonB I do need full screen. I would like to know if the message is critical. How about reduce the size of main window in debug mode?

JonB

I don't think it's "critical". If things work you don't have to worry anyway.
Not sure about your last sentence, but if that's for my debugger use that's not what I'm looking for. Only reversion to Xorg behaviour solves. Maybe in the future the wayland limitations will be addressed.

JoeCFD

@JonB Hopefully not. But some people did report some crashes. But they did not tell their Qt version and OS. I am unable to debug this app with QtCreator and have to build it in Yocto sdk and copy it into the device for testing. This is not a big app and I can handle it without debugger.

If I understand your issue correctly, Qt Creator does not show the source code when the execution hits a break point because your app is always on top. Is it possible to reduce window size in order to see source code and break points? Your app may behave differently on Wayland and X11.

JonB

@JoeCFD
There is not enough screen room to show debugger + app side by side. If you have two monitors may not bother you, I don't. When hitting a breakpoint or signal debuggers have come up-front over the debuggee since year dot. I regard it as unacceptable not to. Creator used to do it fine. It no longer works under wayland. Unacceptable for me. So I have reverted to Xorg and will give up developing if in the future I have to go wayland and they haven't addressed it.

JoeCFD

@JonB I see. It is definitely unacceptable. Wayland has been around for quite some time.

JonB

@JoeCFD
If it doesn't permit a debugger to up-front itself over a debuggee then to me it's "worthless". I'm not sure, but my limited understanding says that Qt provides a "default compositor" for wayland, and the compositor can implement or not implement things. I believe I am hoping for a "compositor update" from Qt....

Axel Spoerl

Two different problems here:

Window activation / Qt version
Wayland support has been improved in Qt 6 and won’t be fixed in Qt 5. If you want to use an outdated version of Qt, you have to accept its shortcomings. Don’t complain.
Creator on top of debuggee
That’s a general issue of all debuggers. You can remote debug though, that’s what I usually do.

JonB

@Axel-Spoerl said in "qt.qpa.wayland: Wayland does not support QWindow::requestActivate()":

Creator on top of debuggee
That’s a general issue of all debuggers. You can remote debug though, that’s what I usually do.

Hi Axel. Is that addressed to my issue? What is "a general issue of all debuggers"? I have used debuggers since the last millennium and they all allow the up-fronting of debugger on top of debuggee when a breakpoint/signal is hit. Creator allows it, and has a setting related to it. And it has worked, and continues to work, for Creator, so long as you use the xcb QPA. The issue is that Wayland, or perhaps the compositor Qt uses, does not allow it.

Scotsgeek

Qt5 on Debian Testing (Trixie) getting the same message:
"qt.qpa.wayland: Wayland does not support QWindow::requestActivate()"

On the page:
https://wiki.qt.io/Qt_version_history
"Complete Wayland support, including the client-side decorations.",
Apparently not. Why would you not fully support Wayland even in Qt5.

I'm not a Qt developer. Just trying to do some debugging of this message for another developer. He cannot port to Qt6 for now. How many other developers are in the same boat?

JonB

@Scotsgeek
Yes, you get that with Qt5.x, Ubuntu 22, Wayland. Nothing you can do about it. It's just a warning, that should not stop you porting 5 to 6. As it happens with Qt6.x, Ubuntu 24, Wayland that message does not appear (though I don't think that means requestActivate() does anything). Still plenty of Wayland issues outside Qt, for my part I have made Ubuntu desktop revert to Xorg.