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



  • 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:
    0_1526096661312_Surface Wayland.png

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



  • 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



  • 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.


  • Qt Champions 2017




  • Qt Champions 2017

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



  • 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.


  • Qt Champions 2017

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



  • @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.



  • 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.



  • @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.



  • @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.



  • @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() )



  • 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.



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



  • @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.



  • 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!



  • 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.

Log in to reply
 

Looks like your connection to Qt Forum was lost, please wait while we try to reconnect.