Wayland support

[jleclanche]

No description provided.

[wp9015362]

Hello,

is there already an ETA for this?

Regards

[kuzmas]

No offence but, If I were you I would not expect to get ETA in a project where everybody is doing it as a hobby. What you really can get is: whether there are plans to do something or not. And because Jerome had already put this request for the Wayland support and I can't see any comments with objections, so the answer is: Yes, we're planning to support Wayland one day.
Best regards!

[luis-pereira]

On Sun, May 18, 2014 at 2:49 PM, Kuzma Shapran notifications@github.comwrote:

No offence but, If I were you I would not expect to get ETA in a project
where everybody is doing it as a hobby. What you really can get is: whether
there are plans to do something or not. And because Jerome had already put
this request for the Wayland support and I can't see any comments with
objections, so the answer is: Yes, we're planning to support Wayland one
day.
Best regards!

No one saying it may do it...... probably means that the ETA, right now,
tends to +INF

    Luís Pereira

[kuzmas]

Ha-ha!
I like your estimation, Luís!
:-D

On 19 May 2014 11:25, Luís Pereira notifications@github.com wrote:

On Sun, May 18, 2014 at 2:49 PM, Kuzma Shapran notifications@github.comwrote:

No offence but, If I were you I would not expect to get ETA in a project
where everybody is doing it as a hobby. What you really can get is:
whether
there are plans to do something or not. And because Jerome had already
put
this request for the Wayland support and I can't see any comments with
objections, so the answer is: Yes, we're planning to support Wayland one
day.
Best regards!

No one saying it may do it...... probably means that the ETA, right now,
tends to +INF

Luís Pereira

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/10#issuecomment-43456864
.

[jleclanche]

With Qt 5 support complete it would be good to look at our blockers for this. Targeting 1.0.

[paulolieuthier]

We are relying on certain X11-specific features from KWindowSystem, that has to be worked out as well. The reason for that is that KWindowSystem's main interface lacks some methods, so that one has to instantiate a NETRootInfo object, which needs a xcb connection.

I've added KWindowSystem::setShowingDesktop(bool) to KWindowSystem in the past. Other missing methods can be easily added as well.

[jeremywh7]

Does this have relevance to helping with Wayland compatibility?
"Qt 5.8 now fully supports its Qt Wayland Compositor"
https://blog.qt.io/blog/2017/01/23/creating-devices-with-multiple-ui-processes-using-wayland/

Are the aforementioned KWindowSystem dependencies still present?

[palinek]

"Qt 5.8 now fully supports its Qt Wayland Compositor"

But we don't want to make our own wayland compositor.

[moosingin3space]

What would you think of integrating KWayland? Martin Gräßlin has been implementing a lot of useful Wayland desktop protocols and is very open about the process on his blog.

Or maybe using libweston/libweston-desktop?

[yan12125]

Or maybe using libweston/libweston-desktop?

My last experience (several months ago) on weston is quite bad. Apparently libweston is designed to demonstrate some basic libwayland usages instead of a complete Wayland compositor.

---

Here I'd like to share my thoughts for this issue. It would be great if LXQt can run on top of common Wayland compositors, including KDE's KWin, GNOME's Mutter or standalone ones like Sway. In the old X11 days, there are NetWM/ICCCM/... standards so that developing cross-window-manager DEs is easy. However, KWin/Mutter/etc. defines lots of different extensions on top of the fundamental Wayland protocol. Take lxqt-panel for example. NetWM allows windows to be docked, and defines "strut" so that maximized windows will not overlap the panel. Weston does not provide such a functionality, and KWin and Mutter use different APIs to dock windows and define struts. Making LXQt compositor-agnostic can be quite complicated. Maybe we can target KWin first.

[PCMan]

@yan12125 I have the same thoughts with you. I tried weston several times but it's far from production use. The existing compositors are not desktop-agnostic and we can no longer use NETWM. There is xdg-shell protocol, but it does not have the same feature set NETWM used to provide.
Supporting kwin first is quite reasonable since we already used KWindowSystem.
Another possible approach is finding a Qt-based wayland compositor which is mature enough, and try to add our stuff to it.

[jeremywh7]

What about Orbital? Could it replace Openbox (etc.), for this purpose? https://github.com/giucam/orbital "Orbital is a Wayland compositor and shell, using Qt5 and Weston. The goal of the project is to build a simple yet flexible and good looking Wayland desktop. It is not a full fledged DE but rather the analogue of a WM in the X11 world, such as Awesome or Fluxbox."

…

On Feb 6, 2017 7:40 AM, "PCMan" ***@***.***> wrote: @yan12125 <https://github.com/yan12125> I have the same thoughts with you. I tried weston several times but it's far from production use. The existing compositors are not desktop-agnostic and we can no longer use NETWM. There is xdg-shell protocol, but it does not have the same feature set NETWM used to provide. Supporting kwin first is quite reasonable since we already used KWindowSystem. Another possible approach is finding a Qt-based wayland compositor which is mature enough, and try to add our stuff to it. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADnmAlv1YZqmeFQWrCsmkn4cHKP5jkdFks5rZxTMgaJpZM4BghSR> .

[yan12125]

When I last tried Orbital a few months ago (about the time of lxqt/lxqt-panel#380), it was quite unstable. It crashed multiple times. On the other hand, weston crashed only one time when I was playing on it. I didn't think it was mature enough. Maybe things are better now. I'll have a look.

UPDATE: It can't even compile this time: giucam/orbital#46

[yan12125]

Today I hear a bad news from Phoronix. KDE refused to support the latest unstable XDG protocol in KWin [1], and now GTK supports only the latest unstable XDG protocol. Sounds like wayland is still a game play between Gnome and KDE, and I guess LXQt has no enough manpower to join the game.

[1] https://bugs.kde.org/show_bug.cgi?id=359531#c8

[tsujan]

Today I tried wayland (for the first time) under KDE with a powerful Intel card. It was a disaster ;) Lagging and lagging and lagging, high CPU usage, kde main menu made plasma crash,...., in short, it was ridiculous. After years of development, wayland is still very unstable! Or Qt's/KDE's wayland support is poor?

I wanted to try it with Enlightenment because they say E works well with wayland but the KDE experience made me hesitate.

[tsujan]

Replying to myself:

wayland is OK with weston (gtk apps work fine) and also with Enlightenment (E apps work fine). So, sadly, the problem is in Qt and KDE.

[yan12125]

How did you run kde with wayland? I've never get it working 😓 2017年2月23日 03:54，"tsujan" <notifications@github.com>寫道：

…

Replying to myself: wayland is OK with weston (gtk apps work fine) and also with Enlightenment (E apps work fine). So, sadly, the problem is in Qt and KDE. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#10 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AB2RGdAg92qgWHfI18Nm6q2u7bQcnklcks5rfJKQgaJpZM4BghSR> .

[tsujan]

How did you run kde with wayland?

I installed plasma-wayland-session. sddm showed it and I just logged in. (The latest Manjaro testing, which should be the same as the latest Arch testing).

Weston also shows many problems with Qt but apparently it works fine with gtk+ and EFL.

[Sunderland93]

wayland is OK with weston (gtk apps work fine) and also with Enlightenment (E apps work fine). So, sadly, the problem is in Qt and KDE.

I daily use KDE Neon Developer Unstable with Wayland, on my laptop with Intel HD Graphics card. It works fine for me. No lagging, no crashing (only with drag'n'drop from/to Wayland apps to/from Xwayland apps). I miss some things: support of Presentation Time protocol, which add video playback, keyboard layout emblem, popup windows and virtual desktop support. But all of these in KDE Phabricator https://phabricator.kde.org/tag/plasma_on_wayland/

[tsujan]

This might be obvious to many but it took me a while to know it:

Using Weston under an LXQt or E session seems to be the easiest way of testing/preparing Qt apps on/for wayland (with QT_QPA_PLATFORM=wayland-egl THE_APP). Weston's wayland session is also fine but, with its X1 output (running weston in QTerminal), the work can be done under LXQt and the result can be tested on wayland.

[yan12125]

Thanks @tsujan. I finally run Plasma on Wayland. I got even worse results than yours: the whole desktop gets stuck after clicking on the main menu of KDE. On the other hand, both weston and KDE on X11 run fine. I use a 5-year-old desktop PC with NVIDIA GTS 450. The OS is Arch Linux.

By the way, I have to replace the proprietary nvidia driver with xf86-video-nouveau. There are reports that the proprietary variant does not work with non-GNOME DEs. [1] I guess that's the reason that KWin refuses to run.

@Sunderland93

I daily use KDE Neon Developer Unstable with Wayland

Sounds great. How did you install KDE Neon?

[1] http://www.phoronix.com/scan.php?page=news_item&px=GNOME-Mutter-Mainline-EGLStream

[jeremywh7]

What are devs' thoughts on this? :-)

[tsujan]

What are devs' thoughts on this? :-)

Well, it's too minimal and not ready to be really used. Their script isn't about LXQt+Wayland either. But it's good to know that there's yet another project about Wayland.

Personally, I'm so satisfied with LabWC+LXQt that it has become my main work place since I started to try it.

Of course, some LXQt components aren't completely ready for Wayland (partly because there's no stable and usable version of layer-shell-qt6 yet), but LabWC provides tools for working around most problems.

[selairi]

Hello,
First of all, sorry for being away from LXQt development for so long.
I have been testing on how to port the taskbar plugin to wayland. I finally got my first successful attempt:
https://github.com/selairi/lxqt-panel/tree/wayland
It's a simple plugin called "plugin-waylandtaskbar". This is a simple screenshot over labwc:

It still needs a lot of work. It is based on a driver that connects to the wayland toplevel protocol and has a DBus interface. From lxqt-panel it is possible to connect to this DBus.
I am thinking that in the future lxqt-panel could change the driver depending on the environment, X11 or Wayland.
There is still a lot of code to clean up and refactor, as I have based it on "plugin-taskbar".
Do you think that it can be included in lxqt-panel?
Thank you for your attention

[stefonarch]

That's nice to hear! Probably you didn't noticed the refactoring PR for plugin-taskbar:
lxqt/lxqt-panel#2029

It could be possible with it to integrate it here maybe, there is already an implementation for kwin_wayland (which works for @gfgit but not for me atm).

[stefonarch]

Oh, I see it needs KF6, but is based on Qt5, right? There will be no qt5-release anymore of LXQt components, the mentioned PR is including port to Qt6 wip_PR.

EDIT: local issue here, had already liblxqt qt6 installed.

[stefonarch]

Maybe we need a dedicated discussion only for discussion taskbar on wayland, because there are several things to consider, like workspace support (probably atm only kwin, sway and hyprland) and so on. It works nicely ;)
Many of the "old" taskbar options are not possible everywhere.

Slowly pieces are falling in place, lxqt-panel from here in Qt6 uses layer-shell-qt v6 and positioning and exclusive zones are working basically also for multiple panels.

[gfgit]

It is based on a driver that connects to the wayland toplevel protocol and has a DBus interface. From lxqt-panel it is possible to connect to this DBus.

Hi! Why did you choose DBus and not implemented wayland protocol directly in panel's executable?
I've never used DBus, it looks interesting, but I think it adds complexity here.

I think we can have multimple backend (X11/Wayland/...) inside main executable or as shared libraries, implemented by deriving a common abstract class.

[Mark-4158]

It is based on a driver that connects to the wayland toplevel protocol and has a DBus interface. From lxqt-panel it is possible to connect to this DBus.

Hi! Why did you choose DBus and not implemented wayland protocol directly in panel's executable? I've never used DBus, it looks interesting, but I think it adds complexity here.

I think we can have multimple backend (X11/Wayland/...) inside main executable or as shared libraries, implemented by deriving a common abstract class.

To my knowledge, going the plugin route allows other plugins to utilize its wlr-foreign-toplevel functionality while still running as a separate process.

[stefonarch]

Labwc doesn't cleanup systemd at exit atm (there is a PR coming), restarting the session the taskbar shows windows from the previous session and is unresponsive.

No idea about the others, will test.

[gfgit]

To my knowledge, going the plugin route allows other plugins to utilize its wlr-foreign-toplevel functionality while still running as a separate process.

With plugin I usually mean a shared library. This would be adifferent thing.
Anyway what's the advantage of splitting panel process from "driver" process?

[selairi]

Hi! Why did you choose DBus and not implemented wayland protocol directly in panel's executable?
I've never used DBus, it looks interesting, but I think it adds complexity here.

@gfgit It is because I am very clumsy. Initially I tried to use qtwayland to implement the wlr-foreign-toplevel protocol , but at that time I didn't have enough knowledge about Wayland, so it didn't work.
I looked for documentation, but I found it easier to learn how to use wayland directly. I ended up writing:
https://github.com/selairi/yatbfw
Someone suggested using Taskmaid. Taskmaid uses DBus to be able to use wlr-foreign-toplevel. That gave me the idea to use DBus to make the requests to the protocol from Qt. It has the advantage that you can make crazy scripts to manage windows from the command line, like minimizing all windows or displaying a terminal when a tar is finished.
With what I know now about Wayland, I could try to use qtwayland to make the connection with Qt, but I don't know if it would be successful.

I think we can have multimple backend (X11/Wayland/...) inside main executable or as shared libraries, implemented by deriving a common abstract class.

This would be the most appropriate solution, but I have not yet succeeded.

[selairi]

Labwc doesn't cleanup systemd at exit atm (there is a PR coming), restarting the session the taskbar shows windows from the previous session and is unresponsive.

@stefonarch I think that it can be solved killing the lxqt_windowlist proccess and restarting lxqt-panel, but I haven't finished plugin-waylandtaskbar yet.

Oh, I see it needs KF6, but is based on Qt5, right? There will be no qt5-release anymore of LXQt components, the mentioned PR is includinghttps://github.com/lxqt/lxqt-panel/pull/2024.

plugin-waylandtaskbar doesn't need KF5 or KF6, it could be removed, but it still is a proof of concept.

Maybe we need a dedicated discussion only for discussion taskbar on wayland, because there are several things to consider, like workspace support (probably atm only kwin, sway and hyprland) and so on. It works nicely ;)
Many of the "old" taskbar options are not possible everywhere.

That is the point, Wayland hasn't got standard methods to control windows or virtual desktops. Each desktop should implement their wayland server and internally define it. Nowadays LXQt is desktop agnostic, then multiple backends could be the best solution, but we are a small project, then we should select a set of official wayland servers for LXQt.
Some features could work in one server but not in another. Example, Sway allows you to use swaymsg to control workspaces, but labwc has no external way to control them.
I believe that in the future Wayland will create new protocols to control these aspects and today it is better to implement simple cases like maximizing or minimizing windows.

[Mark-4158]

To my knowledge, going the plugin route allows other plugins to utilize its wlr-foreign-toplevel functionality while still running as a separate process.

With plugin I usually mean a shared library. This would be adifferent thing. Anyway what's the advantage of splitting panel process from "driver" process?

My understanding is that (1) it is standard practice in these desktop ecosystems to implement their panels using multiple processes and that (2) wlr-foreign-toplevel specifically provides its functionality to processes - not whole programs. Presumably (see SFWBar), having the "window management" plugin process alone use wlr-foreign-toplevel has become standard practice in the case of Wayland panels.

[ammen99]

My understanding is that (1) it is standard practice in these desktop ecosystems to implement their panels using multiple processes and that (2) wlr-foreign-toplevel specifically provides its functionality to processes - not whole programs. Presumably (see SFWBar), having the "window management" plugin process alone use wlr-foreign-toplevel has become standard practice in the case of Wayland panels.

Wayfire's panel uses a single process for everything, as far as I know Waybar also uses one process, so I don't think spawning multiple processes has become the standard for wayland panels. Having a single process actually usually makes things simpler when it comes to Wayland protocols, because different processes cannot share Wayland objects with each other.

[gfgit]

With what I know now about Wayland, I could try to use qtwayland to make the connection with Qt, but I don't know if it would be successful.

I've made a new PR lxqt-panel#2031 which is specific to KWin Wayland.
Would you like to adapt you existing code implementing wlr-foreign-toplevel on top of this? So we get both KWin and wlroots-based compositor support.

[selairi]

I've made a new PR lxqt/lxqt-panel#2031 which is specific to KWin Wayland.

I have seen your code and it looks great.

Would you like to adapt you existing code implementing wlr-foreign-toplevel on top of this? So we get both KWin and wlroots-based compositor support.

Yes, of course. It does not seem very difficult.

[stefonarch]

Demo with kwin, labwc and sway. Labwc doesn't have the issue with popups as normal windows as you can see in kwin and also in sway. No way to test with wayfire and hyprland on Neon, but I'm sure it will be working the same way. Most effects are disabled for speed in kwin.

[gfgit]

In KWin if I launch 2 times same app and enable window grouping in lxqt panel taskbar, context menu to send window to desktop 2 disappears before I can click in it. Only way is to navigate with arrow keys. Sometimes it also crashes panel.

[stefonarch]

In KWin if I launch 2 times same app and enable window grouping in lxqt panel taskbar, context menu to send window to desktop 2 disappears before I can click in it. Only way is to navigate with arrow keys. Sometimes it also crashes panel.

I never used grouping, but yes, it's an issue. If not releasing the mouse button it's possible to navigate and click it.

I opened this for general ideas and to keep together things: #2531

[jeremywh7]

I was curious if anyone has tested KWinFT lately, but went to check its status and found it archived on Gitlab.

Then found a blog post from Roman just today: Qt6, renamed, and moved to Github. It says, "Theseus' Ship can be used as a drop-in replacement for KWin inside a KDE Plasma Desktop session" ...so not sure if it will work outside of that; I seem to recall that KWinFT was meant to be more desktop-agnostic?

[stefonarch]

__" ...so not sure if it will work outside of that.

Some hour ago he showed up on our Matrix chanel and should be about to test it with LXQt ;)

[gfgit]

I was curious if anyone has tested KWinFT lately

I did in the past but having to build all dependencies from source was too much. Now with KDE Neon it should be easier.

[stefonarch]

KF6 and layer-shell-qt are now in [extra-testing].

[tsujan]

I tested layer-shell-qt6 with the Qt6-based pcmanfm-qt's desktop today. Anchoring and layer setting were correct, but there was no keyboard focus or tooltip on Desktop. So, it's still not usable, although it's much better than before (no full-screen menus, dialogs,… anymore).

[Consolatis]

Layershell clients that want keyboard focus are required to request one of 3 keyboard interactivity modes: NONE, EXCLUSIVE or ONDEMAND. ONDEMAND should basically behave like it would be a usual window, how exactly that works is compositor policy. If a layershell client does not request any keyboard interactivity mode NONE is assumed and thus the client will never get keyboard focus.

[tsujan]

Layershell clients that want keyboard focus are required to request one of 3 keyboard interactivity modes

Tried all of them for the sake of certainty. The issue is in layer-shell-qt6, I suppose.

[tsujan]

OK, the tooltip and focus issues seem to be related to labwc.

@stefonarch tried pcmanfm-qt+layer-shell-qt6 with kwin_wayland and found no problem. Then I also tried it there and saw that the desktop had the keyboard focus when needed and as expected. Tooltips were fine too.

[tsujan]

Understandably, most comments are outdated on this page. See #2531 instead. Closing...