Comparing Qt Widgets App under Gnome wayland using platform wayland-egl to xcb

myk321 · wrote on 12 May 2018, 03:50

Under Ferdora 28 and a gnome session under wayland, I have spotted a couple of display differences using the Qt Surface Example started using -platform wayland-egl comapred to started using -platform xcb. I attached a couple of screen-shots below. In particular:

Under xcb, the data visualisation is not displayed and instead a black pane is displayed.
Under wayland-egl, the window decorations are different to xcb and look less platform native; on a HD screen the close button is too small to easily use.
Default font size are bigger under wayland-egl. The header in particular is strangly large under wayland-egl
Under wayland-egl, double clicking the window header when not maximised, does not maximise the window
Under wayland-egl the maximise and minimise buttons, show and hide the data visualization graphic, not the window
The wayland-egl window no longer starts in front
The wayland-egl window no longer starts maximised / at the requested size
On wayland-egl the following are written to the console on startup:
#QSocketNotifier: Can only be used with threads started with QThread
QOpenGLFramebufferObject: Framebuffer incomplete attachment.
Under wayland-egl, under gnome, docking the window on the left or right side of the screen (by dragging the header to the side of the screen) does not cause the window to dock instead the window remains its previous size
Under wayland manipulating the data visulaisation but holding the right mouse results in the following being written to the log:
Unexpected wl_surface.enter received for output with id: 6 screen name: "Screen4" screen model: "0x040a"
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

Whats the best way to proceed with these issues: Do I complete a separate bug report for each issue?

Surface example running under wayland-egl:

Surface example running under xcb (xwayland)
![0_1526096684444_Surafce XWayland II.png]

vithom · wrote on 23 May 2018, 20:14

Hello,

With the new Qt 5.11 version, my application is launched by default with -platform wayland-egl and I notice more or less the same issues.

In my case, default font size is smaller under wayland-egl
#QSocketNotifier: Can only be used with threads started with QThread is written on startup too
docking the window works for me
when I manipulate menus in the menu bar, I show the same errors about Unexpected wl_surface... and qt.qpa.wayland:...
when a window is displayed, its startup position is always in the upper left corner, with the title bar hidden by the gnome's desktop bar (with hour, "activity" menu, etc.) and sometimes its size or its position is suddenly changed.

Is it possible to force the default platform to be xcb with an option in the .pro file for exemple ?

Thanks

myk321 · 26 May 2018, 19:38

Am not aware of something in the .pro to set the platform. Am planning to include a .desktop file to associate the application icon and to allow the Qt application to be added to the dock. The Exec command within the .desktop file allows the executable to be invoked with parameters.

Have logged the data visualisation issue under xcb here: https://bugreports.qt.io/browse/QTBUG-68263

Have switched to KDE plasma (no wayland) as my one man protest against the state of Qt CSD under Gnome.

mrjj · M myk321 25 May 2018, 12:27

@myk321
Hi
You are not alone for wishing for CSD support.
I have seen 1 other person
https://bugreports.qt.io/browse/QTBUG-63969
https://forum.qt.io/topic/84359/how-to-have-my-qt-application-use-gnome-csd

myk321 · 30 May 2018, 14:32

Some additional insight over here: http://blog.qt.io/blog/2018/05/29/whats-new-in-qt-5-11-for-the-wayland-platform-plugin/#comment-1203650

mrjj · M myk321 30 May 2018, 14:30

@myk321
Good news :)
When they iron out the gnome issues.

johanhelsing · wrote on 30 May 2018, 15:44

That's quite a list of issues, I'll go through them one by one and write down what I know:

Under xcb, the data visualisation is not displayed and instead a black pane is displayed.

Should be reported as an xcb bug.

Under wayland-egl, the window decorations are different to xcb and look less platform native; on a HD screen the close button is too small to easily use.

Window decorations are drawn by the client on Wayland, except on compositors that opt-in to server side decorations. Gnome-shell has explicitly stated that they will do no such thing. Starting with Qt 5.11 the window decorations should scale when moving between high-dpi and non-high-dpi montiros. If they don't it might be that you haven't configured the scale factor for your screen. See devices and displays and scale or something along those lines in gnome-control-center.

Default font size are bigger under wayland-egl. The header in particular is strangly large under wayland-egl

It might be that gnome-shell is reporting the wrong physical size for your monitor on either wayland or xcb, which affects DPI and consequently point sized fonts. On Wayland you can run weston-info to see what kind of dimensions the compositor reports. You can also start your application like this env WAYLAND_DEBUG=1 ./myapp and look for a line saying something about the geometry of a wl_output. On xcb I have no idea.

Under wayland-egl, double clicking the window header when not maximised, does not maximise the window

That's something that should be easy to add, you can file a suggestion for it.

Under wayland-egl the maximise and minimise buttons, show and hide the data visualization graphic, not the window

That sounds really weird and you should file a bug for it. Ideally with a minimal example.

The wayland-egl window no longer starts in front

Sadly, clients have no control over stacking order on Wayland, it's left up to the compositor. Don't file a bug for this.

The wayland-egl window no longer starts maximised / at the requested size

I think this should be fixed in 5.11

On wayland-egl the following are written to the console on startup [...]

I don't know why you're seeing that. You should perhaps mention it in the reports you create.

Under wayland-egl, under gnome, docking the window on the left or right side of the screen (by dragging the header to the side of the screen) does not cause the window to dock instead the window remains its previous size

Fixed in 5.11

Unexpected wl_surface.enter received for output with id: 6 screen name: "Screen4" screen model: "0x040a"

This probably just means the compositor is misbehaving slightly, it shouldn't be a problem (we might remove that warning or only show it in a logging category).

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

This means your window tried to grab focus in the compositor, which is not allowed in wayland. Don't create a bug for it, there's nothing we can do.

mrjj · wrote on 30 May 2018, 15:59

Hi
Super write up.
And welcome to the forums ;)

johanhelsing · 6 Apr 2018, 07:36

@mrjj: Thanks :) It's easier to get my attention if you file bugs, though. And remember to add the wayland component to the issue.

@myk321: Not sure how notifications work here... Anyway, I answered your questions in my previous post.

@vithom:

when a window is displayed, its startup position is always in the upper left corner, with the title bar hidden by the gnome's desktop bar (with hour, "activity" menu, etc.) and sometimes its size or its position is suddenly changed.

I'm pretty sure this is a gnome-shell issue, I don't see it on other compositors. Trying to get a response from gnome-shell devs now: https://gitlab.gnome.org/GNOME/gnome-shell/issues/321

Is it possible to force the default platform to be xcb with an option in the .pro file for exemple ?

Sadly, we in the Qt Wayland team didn't know that Wayland was suddenly set as default when XDG_SESSION_TYPE was set. That totally went under our radar, and we've been working under the assumption that Wayland still wasn't the default in gnome-shell wayland sessions.

If you unset XDG_SESSION_TYPE, you should get xcb instead of wayland, i.e. do something like this in your main() (untested):

if (qgetenv("XDG_SESSION_TYPE") == QByteArrayLiteral("wayland")) {
    qWarning() << "Warning: disregarding XDG_SESSION_TYPE=wayland";
    qWarning() << "To use wayland anyway, please set QT_QPA_PLATFORM=wayland";
    qunsetenv("XDG_SESSION_TYPE");
}

EDIT: fixed typos in code.

myk321 · 1 Jun 2018, 13:53

The issue with data visualisation being displayed as a blank panel under xwayland is logged here: https://bugreports.qt.io/browse/QTBUG-68263
and here: https://bugs.freedesktop.org/show_bug.cgi?id=106757

The issue with the minimise button minimising the data visualisation, but not the window is now logged here: https://bugreports.qt.io/browse/QTBUG-68576

The issue with the default font size not being set under wayland is now logged here: https://bugreports.qt.io/browse/QTBUG-68577

The suggestion to enable double-click to maximise and restore window size is logged here: https://bugreports.qt.io/browse/QTBUG-68578

The issue with the error logs on application startup is now logged here: https://bugreports.qt.io/browse/QTBUG-68579

Johan, I understand that CSD is a quagmire, but we'd like to understand Qt direction so we can plan accordingly. I surmise from your comment above, that Qt's position on wayland CSD is to support SSD if its available (e.g. under KDE Wayland) and if SSD is not available to fall-back to a generic "Qt Default Window" (e.g. under Gnome-shell), which will look something like the window we see today under Qt 5.11 ie. blue title bar, black text, maximise, minimise and close right aligned. Is this a fair statement of Qt's direction? or it more a case that the official Qt position on wayland CSD has not yet been decided? I really don't mean to put you in a corner here, so if you'd rather someone else from Qt answer, or that you let us know a time-frame when this will be made know, also completely fine.

johanhelsing · wrote on 1 Jun 2018, 13:53

@myk321 : Thanks for reporting!

Btw, you should be able to work around the font size issue by setting QT_WAYLAND_FORCE_DPI=96.

My opinion on the the future for CSD/SSD is that compositors that wish to draw decorations should be able to.
We will implement support for xdg-decoration when/if that gets merged into wayland-protocols, but it's still being reviewed atm.

I'm not opposed to implementing KDE's server decoration protocol either, but I'm also not going to write the patch for that myself. If I remember correctly. its license is also incompatible with Qt, but that's perhaps possible to solve if someone asks the authors to relicense it.

About the current decorations: I think they are very ugly and would like the default style to look nicer. I'm not sure when or even if I have the time to work on it, though. There were people outside The Qt Company that started looking at it, but I haven't heard anything in a while, so not sure what happened.

myk321 · wrote on 1 Jun 2018, 14:25

@johanhelsing - great, thank-you!

I've added a couple of addition wayland specific defects earlier today, including:
QTBUG-68599 - Unable to Drop when doing Drag n Drop under Wayland
QTBUG-68601 - Qt Applications Not Show under Wayland Gnome Activities Overview
QTBUG-68602 - Qt Applications Crashes Wayland Gnome Shell

As a suggestion: for Eclipse to help organise the wayland related defects on bugzilla, we created a umbrella "Improve Eclipse under Wayland" defect and then linked the individual point defects as depedencies to the umbrella defect. Having this umbrella defect made it somewhat easier to check what had already logged and what what still needed to be fixed. I see on the Qt Bug Reports site there is a concept of a sub-task (not sure if this works the same as dependency). Anyway, I've tagged each defect with 'Wayland', but please let us/me know if there is anything else I/we can do to make this easier to manage.

vithom · wrote on 1 Jun 2018, 20:22

@johanhelsing said in Comparing Qt Widgets App under Gnome wayland using platform wayland-egl to xcb:

@vithom:

If you unset XDG_SESSION_TYPE, you should get xcb instead of wayland, i.e. do something like this in your main() (untested):
if (qgetenv("XDG_SESSION_TYPE") == QByteArrayLiteral("wayland")) {
    qwarning() << "Warning: disregarding XDG_SESSION_TYPE=wayland";
    qwarning() << "To use wayland anyway, please set QT_QPA_PLATFORM=wayland";
    qunsetenv("XDG_SESSION_TYPE");
}

Thanks for this solution, it works perfectly (just with qWarning() instead of qwarning() )

johanhelsing · 6 Apr 2018, 09:44

Due to all the problems on gnome shell, we will probably unset Qt Wayland as the default in Qt 5.11.1 (and use xcb instead). If we get the serious bugs fixed, we will consider switching back to Wayland in Qt 5.12, though. Relevant patch: https://codereview.qt-project.org/#/c/231227/

I also created an umbrella task to cover things that should be fixed before we can switch the default back to Wayland: https://bugreports.qt.io/browse/QTBUG-68619

So unless you know your users are going to stay on 5.11.0 and not upgrade to 5.11.1 for a long time, you shouldn't need to apply the workaround I posted earlier.

myk321 · wrote on 13 Jun 2018, 15:33

Some more insight into further improvements for Qt6 under Wayland detailed here: https://bugreports.qt.io/browse/QTBUG-68847

johanhelsing · wrote on 14 Jun 2018, 06:28

@myk321 : Note that that task is only about the stuff we can't easily do in minor releases. I.e. removing stuff, changing behavior, renaming imports.

Most of the bug fixes, improvements and new features will be done in 5.x releases in years to come.

myk321 · wrote on 5 Jul 2018, 15:26

https://www.phoronix.com/scan.php?page=news_item&px=Wayland-Protocols-1.15

Seems that the XDG extension is progressing into Wayland 1.15 - fingers cross that Gnome supports the extension!

myk321 · wrote on 18 Sept 2018, 12:03

Looks like there are some exciting improvements in Qt 5.12 (http://wiki.qt.io/New_Features_in_Qt_5.12), including:

Added support for xdg-shell stable (and deprecated unstable v5).
Made the default window decorations look nicer.
Added support for the Wayland extensions: xdg-decoration-unstable-v1, xdg-output-unstable-v1.

myk321 · wrote on 6 Oct 2018, 00:55

Default CSD on Qt 5.12 on Gnome 3.28, looking much better - funny colours and font sizes are gone :-)
Have logged:
QTBUG-70971: Mouse pointer increases in size when over a Qt Wayland Gnome window

myk321 · wrote on 12 Nov 2018, 06:34

Have played about some more with Qt 5.12 Beta 4 under Fedora 29, KDE 5.13.5 (KDE Frameworks 5.51) and Gnome 3.30.2 and have opened:
Issue 1: No Window Decorations Under KDE Wayland (https://bugreports.qt.io/browse/QTBUG-71720)
Issue 2: Data Visualisation broken under Wayland (https://bugreports.qt.io/browse/QTBUG-71721)

Happily the issue that I had reported previously (https://bugs.freedesktop.org/show_bug.cgi?id=106757 and https://bugreports.qt.io/browse/QTBUG-68263), where the surface example did work under XWayland, is now resolved, althought it does display a bunch of messafe logs in the form:
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (8 8 8 0)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 8 8 0)
qt.glx: qglx_findConfig: Failed to finding matching FBConfig (1 1 8 0)
So I've closed this issue noting that it appears resolved by Mesa 18.2.4.