lxqt
Wayland support
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!
On Sun, May 18, 2014 at 2:49 PM, Kuzma Shapran [email protected]:
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
Ha-ha! I like your estimation, Luís! :-D
On 19 May 2014 11:25, Luís Pereira [email protected] wrote:
On Sun, May 18, 2014 at 2:49 PM, Kuzma Shapran [email protected]:
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/lxde/lxde-qt/issues/10#issuecomment-43456864 .
With Qt 5 support complete it would be good to look at our blockers for this. Targeting 1.0.
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.
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?
"Qt 5.8 now fully supports its Qt Wayland Compositor"
But we don't want to make our own wayland compositor.
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?
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.
@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.
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" [email protected] 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 https://github.com/lxde/lxqt/issues/10#issuecomment-277669439, or mute the thread https://github.com/notifications/unsubscribe-auth/ADnmAlv1YZqmeFQWrCsmkn4cHKP5jkdFks5rZxTMgaJpZM4BghSR .
When I last tried Orbital a few months ago (about the time of lxde/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: https://github.com/giucam/orbital/issues/46
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
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.
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.
How did you run kde with wayland? I've never get it working :sweat:
2017年2月23日 03:54，"tsujan" [email protected]寫道：
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 https://github.com/lxde/lxqt/issues/10#issuecomment-281783773, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2RGdAg92qgWHfI18Nm6q2u7bQcnklcks5rfJKQgaJpZM4BghSR .
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.
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/
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.
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
I got even worse results than yours
That may be because of nVidia.
Anyway, There are still serious problems in the wayland support of Qt (5.8), let alone KDE. For example, QWidget::move() doesn't work and drag-and-drop is buggy. It might get better a few months later but it's already enough for preparing Qt apps for wayland, as I mentioned above.
Here's an interesting reading material from Phoronix: http://phoronix.com/scan.php?page=news_item&px=Wayland-Compositors-Less-2017. If I have time I may look into them and see what's the status for XDG shell protocols and NETWM-like extensions in those compositors. Note that Qt support in compositors is not necessary. LXQt applications are standalone ones and should be able to run on any compositor. For example Openbox is written in C with pango, which seems highly related to GNOME and GTK+.
@yan12125 Thanks for the link!
To make Kvantum and FeatherPad work under wayland, I just had to add conditions to leave out x11 parts of the code when the program was running under wayland. For Kvantum, I had to add some extra codes but that was because of the nature of the program.
Of course, under wayland, some nice features related to virtual desktops are disabled. I think no Linux user could accept a single desktop. So, wayland isn't ready yet -- and not just because of virtual desktops.
Just wanted to add that wayland is still terrible here with plasma 5.9.5. Worse than that, weston doesn't work with Intel modesetting driver (which works fine, while xf86-video-intel has many issues).
EDIT 1: By weston I meant the command weston under X11 -- weston session works.
EDIT2: Something should have been changed because weston (under X11) doesn't work with xf86-video-intel either anymore.
Om my 2 machines (intel video) plasma 9.5.1-1 with xf86-intel-video wayland works stable and fine -actually one of them is an 10 years old laptop and the session uses only about 340mb ram and is very responsive. Only issues I found are logout hanging and yakuake window. But on one machine I had to delete all plasma* configuration files first. Same for weston, works well under X11 here.
actually one of them is an 10 years old laptop
I think that's the causes. The laptop I used for teasing is 1-year old.
What I found recently:
(1) @stefonarch, xf86-intel-video is full of bugs with newer laptops/computers. On the other hand, modesetting works like a charm after uninstalling xf86-intel-video and removing its config from "/etc/X11/mhwd.d/" and "/etc/X11/xorg.conf.d/" (with care). Debian says, "The use of this driver is discouraged if your hw is new enough (ca. 2007 and newer)...". The same is true for Arch and its derivatives.
(2) Out of curiosity and after 4 years, I installed Gnome and saw that it had a very nice wayland support by default, at least on Intel machines.
As I said I've no problems at all using KDE plasma wayland 5.10 with Card: Intel Haswell-ULT Integrated Graphics driver: intel Resolution: [email protected], quite new fanless PC.
Just one known bug about kaccess crashing on session start. Tried to start some LXQt components on Weston, panel was working except position in the middle of the screen.
UPDATE: removing driver and /etc/X11/xorg.conf.d/20-intel.conf works, but I see no difference. Liri sometimes worked well too sometimes, also it's alpha I guess.
As I said I've no problems at all using KDE plasma wayland 5.10
For me and on two Intel based laptops, Enlightenment and Gnome are excellent and quite usable with wayland while KDE Plasma wayland 5.10 is still laggy and buggy. For example, when I log out of Plasma wayland, several apps crash and it takes a while for sddm screen to appear. That's while when I log out of Gnome to gdm (on another but not so different machine, with the same distro on it), no crash happens.
This might be of interest: https://liri.io/blog/2017/01/01/welcome-to-liri.html "Liri is the merge between Hawaii, Papyros and the Liri Project."
https://medium.com/liridev/liri-roadmap-for-2017-3678334da215 '... The shell is “just” a Qt app, [which] with QtWayland Compositor and eglfs it implements a Wayland windowing system that you can run on [a] wide variety of targets like KMS or embedded platforms such as Broadcom (Raspberry Pi), Vivante (Wandboard), Mali, etc… The liri-wayland repository holds a fork of eglfs with more features such as logind integration, screen hot plugging, resolution change, EDID parsing to get more screen information, on the other hand eglfs progressed quite a lot in the past months and has now support for NVIDIA binary blob. The goal here is to upstream the changes in order to be able to use eglfs in the future and leave the Qt folks with maintenance duties. The plan is to make the shell 1.0 available in late Q4 2017.'
The source and additional notes are on github: https://github.com/lirios/shell
At first, that may seem odd. Is a "windowing compositor" a kind of "graphical shell"? Or, is a "graphical shell" something that runs on top of a "windowing compositor"? Well, using QtWayland, the compositor is just a Qt app, so the distinction seems to blur. Maybe lxqt does not need to build on something as distinct as kwin or mutter, and can be built much closer to QtWayland itself?
Maybe lxqt does not need to build on something as distinct as kwin or mutter, and can be built much closer to QtWayland itself?
LXQt has no dependency on any window manager/compositor and works with all as far as they are modular.
Is there any protocol that can manage windows and desktops in wayland session, that lxqt-panel can use?
I tried to make lxqt-panel work under kwin_wayland but I haven't found any KDE interface to manage desktops in a way it is done with x11 at the moment.
4 months after my last test, KDE's wayland session is much better now. No extra CPU usage and no lagging anymore. pcmanfm-qt doesn't crash under it either. This is very promising but still way behind x11. Switching between virtual desktops is problematic, there's no cube animation, mouse gesture doesn't work... In short, KDE/Plasma wayland is not ready, unless a minimum functionality is tolerated.
The wayland WM's of Arch's list (https://wiki.archlinux.org/index.php/wayland) are either elementary or not developed for a long time. It seems that the best option for Qt is kwin (can't try lirios yet).
From my tests liri eats more memory. Probably beacause of qml and js. On KDE plasma under wayland all qt5 apps resizing and scrolling looks more smooth than under x11.
On KDE plasma under wayland all qt5 apps resizing and scrolling looks more smooth than under x11.
Not for me but better than 4 months ago. Maybe I should test again 4 months later. This is a Lenovo Ideapad Y700 with a nice integrated Intel card and nvidia (that I don't use).
BTW, here systemsetting crashes easily under wayland... didn't have time for more tests
I give liri-shell a try. It works fine with nouveau. (not working with nvidia's proprietary binary driver - https://github.com/lirios/shell/issues/96). Runs smooth. Kinda good.
Installing liri-shell-git from AUR brings quite a few dependencies. Apparently most of them are not necessary for a wayland compositor and I guess they can be easily avoided.
$ pacaur -S liri-shell-git
:: Package liri-shell-git not found in repositories, trying AUR...
:: resolving dependencies...
error: package 'boost' not found
error: package 'boost' not found
error: package 'modemmanager-qt' not found
error: package 'modemmanager-qt' not found
error: package 'networkmanager-qt' not found
error: package 'networkmanager-qt' not found
error: package 'paper-icon-theme-git' not found
error: package 'paper-icon-theme-git' not found
error: package 'qbs' not found
error: package 'qbs' not found
error: package 'qt5-graphicaleffects' not found
error: package 'qt5-graphicaleffects' not found
error: package 'qt5-gstreamer' not found
error: package 'qt5-gstreamer' not found
error: package 'qt5-quickcontrols2' not found
error: package 'qt5-quickcontrols2' not found
error: package 'qt5-tools' not found
error: package 'qt5-tools' not found
error: package 'qt5-wayland' not found
error: package 'qt5-wayland' not found
error: package 'ttf-roboto' not found
error: package 'ttf-roboto' not found
error: package 'xcb-util-cursor' not found
error: package 'xcb-util-cursor' not found
error: package 'xorg-server-xwayland' not found
error: package 'xorg-server-xwayland' not found
:: looking for inter-conflicts...
AUR Packages (11) Old Version New Version
aur/fluid-git latest
aur/libliri-git latest
aur/liri-platformtheme-git latest
aur/liri-qbs-shared-git latest
aur/liri-shell-git latest
aur/liri-wallpapers-git latest
aur/liri-wayland-git latest
aur/liri-workspace-git latest
aur/qt5-accountsservice-git latest
aur/qt5-gsettings-git latest
aur/vibe-git latest
Has any work been done for making LXQt ready for Wayland? I haven't investigated it yet but I think pcmanfm-qt runs with xwayland under Plasma Wayland or Gnome-Shell. I don't know about lxqt-panel.
For lxqt-panel lxde/lxqt-panel#380 is the first step. It enables testing on wayland. Quite a few functions are still missing, though.
Me again, with another test -- actually, 3 tests.
KDE is still as before: tolerable but not ready for daily use. The CPU usage is low most of the time.
Gnome-shell is better but its animations aren't as smooth as under X. It has a high CPU usage sometimes.
Wayland-Enlightenment is unparalleled: very smooth, even better that X-Enlightenment, without extra CPU usage. Qt apps that support wayland run fine under it but pcmanfm-qt doesn't start -- I think that's easy to fix. Advanced users of Arch-based systems can have it easily by using the git PKGBUILDs but it should be started from tty with enlightenment_start -- sddm and gdm can only start X-Enlightenment.
EDIT: With sddm-0.17.0 and E-0.22.1, E has a wayland session in sddm -- at least in Arch.
I'm using Weston, it has a few glitches and one annoying bug where most of the drop-downs are incorrectly positioned. Nevertheless, it is usable. It's also very minimal, for the better and the worse. LXterminal (0.3.1) is my default terminal. It works great somehow, looks great, does not exhibit any glitches or bugs, and runs on top of Wayland. I cannot capture the keystrokes when using it, as I would with an app that runs over X.
I think most problems that you would encounter in a wayland-based system are with apps built on X and which use the Xwayland compatibility layer. "Native" wayland apps, or those that exclusively use a toolkit which supports Wayland (such as Qt5) seem to be doing fine.
Can we run lxqt panel under Weston?
Theoretically, yes. Please tell about your experience.
Having seen the recent comments, I tested Plasma wayland again: it was like the last time.
Enlightenment aside, When I test wayland with KDE or Gnome and only see that windows can be moved and minimized under it without crashing, I get happy. However, that simply means I have very low expectations of it; in other words, wayland is still inferior to X11.
Frankly, I think it'll be inferior to X11 even if it gets stable -- Compiz is possible with X11; will something like it be possible with wayland? I hope but don't think so. And I won't like something that just works...
Update: the order is changed here:
I hate Gnome but gnome-shell-3.28 gives me a smooth and problem-free Wayland experience. I've set QT_QPA_PLATFORMTHEME to lxqt, QT_STYLE_OVERRIDE to kvatum, the file manager is pcmanfm-qt, text editor is featherpad, terminal is qterminal, browser is falkon, and although gnome-shell doesn't have a systray (a serious drawback), feathernotes uses its dock on closing. So, gnome-shell+ wayland is quite usable with Qt5 apps. Even gnome's ugly titlebar changes to dark with Kvantum's dark themes (the code isn't mine)! Whatever I do, I can't make anything crash.
E started to crash every now and then with Wayland.
KDE is like before and feels heavy -- there's a delay somewhere and CPU usage gets high suddenly. Also, systemsettings crashed a few times.
Can we run lxqt panel under Weston?
I believe it will be broken somehow (I might have tried). Anyway I'll give it a try and let you know.
@tsujan in GNOME Shell Qt5 apps running on XWayland. You need to set QT_QPA_PLATFORM=wayland, but here is a lot of bugs with Qtwayland, for example - bugs with xdg-popup https://bugreports.qt.io/browse/QTBUG-66456?jql=text%20~%20%22xdg-popup%22
In my Plasma experience, it works pretty cool, exept on Nouveau, where it completely freeze.
in GNOME Shell Qt5 apps running on XWayland...
@Sunderland93 I know that (→ https://github.com/lxqt/lxqt/issues/10#issuecomment-282144653 -- it's QT_QPA_PLATFORM=wayland-egl). Once in a while, I tell about my Wayland experience with those DEs. If one of them works without problem, we could say Wayland is ready. The infamous Gnome is the winner for now. And I agree with you: Qt isn't still ready for wayland; it works but there are issues.
EDIT: Whenever I can enable window translucency with wayland in Kvantum and move windows by grabbing them from anywhere, I'll say that Qt works fine with wayland.
@Degenerate76 You probably know how many effects Compiz has -- I'm enjoying them. Old-fashioned people like to rotate their desktop cube and enjoy a panoramic view once in while, play with wobbly windows after lots of coding, see elegant blurring behind their translucent terminals, etc. I'm sure many Linux users have seen Windows users' reactions when they see how easily those effects are performed under a Linux installation. But, right now, even Qt window translucency isn't possible with wayland (I've disabled Kvantum's window translucency under wayland in its code because it's a disaster), let alone blurring-behind.
I'll be very glad if such features -- which are almost taken for granted with X11 -- become possible with wayland at some point but I don't delude myself. Years have passed and we should be happy that we can move windows by grabbing their ugly title-bars without problem under wayland. The word "regression" comes to mind easily...
And, frankly, I'm suspicious about the idea of starting from zilch instead of improving something that works.
BTW, I'll test window translucency (through the style plugin) and moving windows by grabbing them from anywhere with Qt-5.11+wayland soon. Menu translucency works at last.
@tsujan It sounds like you're talking about limitations of the Weston reference compositor, rather than limitations of the Wayland protocol.
That's right. However, the current poor wayland compositors are what users can experience about wayland. In this sense, which is practical, wayland is not ready. So far, perhaps except for gnome-shell and E, what I've seen has been very elementary or has required rituals to start something elementary -- have't tried wlroots though (and won't if it requires rituals too).
have't tried wlroots though (and won't if it requires rituals too).
wlroots is a library for build Wayland compositor. It's quite simple. You do not need to worry about some low-level things. It also have reference compositor - rootston
I represent the wlroots project, which is being used to build several Wayland compositors (7 to date). It's pretty mature and we're prepared to help you use it if you so desire. I'm not sure what rituals you refer to, but starting a wlroots-based compositor is as simple as running the binary. You can also configure them to show up in login managers that support Wayland.
Rituals: Pray before start wayland, having a black cat and a raven on the shoulder, make the Wayland God gracious by animal sacrifices, reading documentation in the big glass ball ... sorry, couldn't resist, you asked for it.
That's not particularly helpful. This stuff is pretty stable and Just Works so long as you aren't using the Nvidia proprietary driver (and you shouldn't be doing that anyway).
that recommendation isn't particular helpful if one owns a nvidia card and has to run plasma from time to time.
What the hell does that mean? The Nvidia proprietary driver is the only way to get acceptable performance with an Nvidia card.
I don't intend to fight with 20 people over this. Use nouveau or make better choices as a consumer. You can get perfectly reasonable performance with nouveau.
I have personally done it. I'm not making it up.
Like I said, I don't intend to fight with 20 people over this. How about steering the discussion back towards Wayland?
Well the problem with that is that like you said, it's not at all stable on the Nvidia proprietary driver which many people use, because it's the only way to get reasonable performance.
Well - we can calm down now - we will watch the wayland development closely - and sorry, if we are not so happy with the current state - at least we see some moves in the right direction in the last years, @tsujan mentioned gnome-shell and E.
Maybe there is a cultural difference between the wayland community and us - the ideal case would be we can use components that are ready to use and haven't to re-invent the wheel. Maybe more clear: Right now we can chose a certain X-WM with LXQt - so our users can chose what they are happy with - and you expect us to give up these options? NOT really. So i guess wayland have to wait until it is stable and ready for usage.
Your impression of the "current state" of Wayland seems a few years out of date. Try not to drink the kool-aid of Wayland naysayers. The Wayland community is not a homogenous entity which holds a single opinion - the wlroots team and the compositors we represent on the whole agree with you. We are working to develop interopable standards that work from many compositors - this is a core goal of our project. Regarding your specific concern, we have been working with KDE to get the Plasma shell working on other compositors (which is similar to using arbitrary X11 WMs with LXQt). This is far from the only initiative we're undertaking.
You can be hostile and rude or you can work with us from a position of mutal respect and cooperation. Make your opinions known and we'll work with you towards realizing them. The wlroots project is designed to be accomodating.
Your impression of the "current state" of Wayland seems a few years out of date
"Impression"?! Really?!... No comment.
Another criterion to know when Wayland is ready: when it doesn't need to be advertised but really works.
Congrats - you successfully set the date for a re-evaluation of wayland to: Next year, same time - i'm out of this game until then. Please @all - if something important happend meanwihile - wake me up.
PS: Appart of this we should continue to get independend of X - just to be prepared ...
if something important happend meanwihile - wake me up.
I'll keep an eye on wayland + Qt.
Appart of this we should continue to get indipendend of X - just to be prepared
Yes, certainly. That's easy and we've been doing it for a long time.
Hey - i'm only partially sleeping - i'm only out of this wayland thingy until next year.
Something I've been observing for a long time -- something I can't overlook: Like systemd, like gnome3, like..., Wayland has its origins in Red Hat. I won't start a discussion on this and won't say another word about it here -- there's no "but" ;)
Hi Drew. I'd like to say something consoling. I'm not an lxqt developer, just a user. I appreciate your work, partly because I have little better stability with X11 than I do with Wayland compositors. With the latest xorg 1.20 X server, I have display corruption on both radeon hardware and on nvidia hardware. I am still in dialog wth a couple of X11 developers to even discover where the problem occurs. Is it KMS? DRM/render? The X11 server? Nobody really knows. I also have issues with kwin_wayland, where crashing the X11 Xwayland will catastrophically lock-up the user interface. And, to add insult to injury, KDE does not consider this to be a security issue, or any reason to use nonblocking calls to Xwayland.
So, for me, anything you can make work in a Wayland compositor is a step forward. And still, as a project leader you have the dual role of therapist, addressing to the frustration of users who have repeatedly crashed and burned, searching for a way forward with Wayland. I haven't seen much sympathy from Weston or kwin. Really basic functionality is still not available, like direct cut and paste, setting per output display modes/timings, or per output gamma correction. Many Wayland developers are off in their own worlds, rather than attempting to cater to end users.
If you would, please, consider addressing end user issues, one step at a time, and maybe remaining a bit thick-skinned for the moment, your efforts will have an impact, and I, for one, with be thankful.
James
Drew, BTW, if you could pick a particular compositor, and get some buy-in from the developer, we all could have a practical conversation about wlroots. For instance, waybox, by Joe Wisdom, looks like it is in active development, and has the stated goal of providing something familiar to lxqt, "An openbox clone on Wayland".
It should be straightforward to combine wlroots, waybox, and lxqt, and then start talking about what works and what is missing, one step at a time. Would you be willing to do that?
I am not an Xorg expert and I do not represent the KDE project, so I'm not sure I can help you with those troubles. KDE's Wayland support is one of the weaker offerings on the platform, and wlroots (and my own sway compositor) has been working with them to help them shore up their weak points. Please do not judge the entire Wayland ecosystem on KDE's merits.
Really basic functionality is still not available, like direct cut and paste, setting per output display modes/timings, or per output gamma correction. Many Wayland developers are off in their own worlds, rather than attempting to cater to end users.
I'm not sure what "direct cut and paste" is. Clipboard support works on both Wayland and Xwayland, and primary selection support has become stable in the past year or so. Setting per output modes (timings here refers to refresh rate?) is also working in most compositors, including wlroots-based ones. Per output gamma correction is also working (for maybe two years now) but hasn't reached a broad consensus (all wlroots-based compositors, and a handful of others including KDE, are in agreement).
It should be straightforward to combine wlroots, waybox, and lxqt, and then start talking about what works and what is missing, one step at a time. Would you be willing to do that?
The generally agreed upon best way of going about this sort of work would be to add a Wayland compositor to LXQt, then move what we'd call LXQt's "shell" (the panels, wallpaper, etc) into components which are portable across compositors. This is slightly different from the traditional X11 WM approach but can solve many of the same problems. The goal of wlroots is to provide facilities that make this approach easier (and more correct).
If you want to talk to a compositor developer rather than a wlroots developer, I can just change hats real quick. I'm also the maintainer of sway. Sway oversees the wlroots project.
During the last time I looked at Wayland protocols, it seems that it's not possible to place a window at a given position on the screen. lxqt-panel needs this feature to place itself at the top/bottom/left/right of the screen. How's the current situation?
We have developed a protocol for that specific purpose:
https://github.com/swaywm/wlr-protocols/blob/master/unstable/wlr-layer-shell-unstable-v1.xml
It's implemented in several compositors and expected to be in several more, and there are a decent number of clients coming out now (including panels, lock screens, notification daemons, screenshot selection tools, etc).
We're still negotiating on standardizing this protocol but I would not expect it to drastically change.
Looks like lxqt-panel needs some Wayland-specific (or maybe wlroots-specific is more accurate) codes to achieve absolute positioning? That would be a maintanence burden, considering things might be changed in the future. Currently lxqt-panel just calls setGeometry() from Qt and the latter does all the platform-specific work (e.g., passing the request to the X server via XCB). If there's a Qt platform plugin targeting wlroots, just like KWayland targeting KWin, things will be simpler.
Looks like lxqt-panel needs some Wayland-specific (or maybe wlroots-specific is more accurate) codes to achieve absolute positioning?
Never! If wayland requires that, wayland is crap. However, I don't think the situation is so ridiculous -- or I hope it isn't.
Currently lxqt-panel just calls setGeometry() from Qt
That should be enough. If not, there's a bug either in Qt's wayland support or in the wayland compositor.
@yan12125 - thanks for the technical part - @SirCmpwn our problem right now is that we want to be as flexible as possible - you mentioned the protocols part and the lack of standards already. And i agree with @tsujan to some extend that it can't be our part to implement wayland specific things, the framework should do that. Looking forward how this will work.
I'm not sure what "direct cut and paste" is.
On X11, I hold left mouse and highlight, then position the cursor and middle mouse, to paste. On Wayland compositors, I hold left mouse to highlight, then right mouse for a menu, then left mouse to select "Copy" or "Cut". Next, position the cursor, select right mouse for a menu, then left mouse to "Paste". That is three extra steps for a simple Copy and Paste, or two extra steps for a Cut and Paste.
Setting per output modes (timings here refers to refresh rate?) is also working in most compositors, including wlroots-based ones. Per output gamma correction is also working (for maybe two years now) but hasn't reached a broad consensus (all wlroots-based compositors, and a handful of others including KDE, are in agreement).
These are the sorts of things normally provided by xrandr. Thus far, there is no "wrandr" utility. In the past, Weston has been hostile toward offers to provide such a utility. Weston supports setting modes on start-up, which works fine, but, for instance, kwin_wayland seems to have no way to set a correct mode when it defaults to a mode that does not work.
I have yet to see any Wayland compositor or Wayland utility that will allow me to set the color gamma per output, where I run three screens and want the colors to match across the display.
I'm also the maintainer of sway.
"Sway is tiling Wayland compositor" I don't mean to be rude, but I am not a tiling fan, and this is not what is commonly used with lxqt, which defaults to Openbox.
Additionally, for the present, there would have to be support for the Xwayland server, for backward compatibility.
that it can't be our part to implement wayland specific things
Anyone that says otherwise doesn't have any idea -- or pretends that he/she doesn't? -- what a nonsense the opposite would be. Sorry but enough is enough. Let's hope Linux will make sense...
@tsujan Please keep your cool and stay technical. We don't need this thread to go off the rails for such minor reasons.
@jleclanche Technically, it isn't a major reason -- don't have time to explain the obvious.
One thing to do towards wayland is to support panel positioning. I think in wayland protocol there is no common way to do so, and implementation differs across compositors. The second thing that I got stuck when trying to run LXQt components under wayland was lack of protocol to interact with virtual desktops, it seems that there is no such concept in wayland world and again it is compositor specific. Do you have any updates on that?
It would be nice to integrate LXQt as standalone apps into existing compositor. As long as protocol on missing feature from Xorg gets stabilized we can add support of it in the LXQt. All copy-past and nvidia holly-wars are not relevant here because it is a job of the compositor but LXQt apps as a client apps should support protocol.
Looks like lxqt-panel needs some Wayland-specific (or maybe wlroots-specific is more accurate) codes to achieve absolute positioning? That would be a maintanence burden, considering things might be changed in the future. Currently lxqt-panel just calls setGeometry() from Qt and the latter does all the platform-specific work (e.g., passing the request to the X server via XCB). If there's a Qt platform plugin targeting wlroots, just like KWayland targeting KWin, things will be simpler.
This does exist, actually:
https://github.com/SirCmpwn/qtlayershell
This needs some polish but I would love your help with it.
Never! If wayland requires that, wayland is crap. However, I don't think the situation is so ridiculous -- or I hope it isn't.
Listen, you need to fix your tone. If you aren't interested in helping with Wayland support then you have no place in this GitHub thread.
The layer shell does it differently, but that doesn't make it crap. Instead of absolute positioning, you can specify that you'd like to be anchored to an edge. This also allows the compositor to cleanly resolve situations where, for example, there are several panels, or where there are notifications which don't want to occlude the panel.
If you really want absolute positioning, there's no reason you couldn't write a protocol extension which supports it. I don't think you'd find much enthusiasm for its adoption across the rest of the ecosystem, though, and your panel would be unlikely to work on other compositors.
On X11, I hold left mouse and highlight, then position the cursor and middle mouse, to paste. On Wayland compositors, I hold left mouse to highlight, then right mouse for a menu, then left mouse to select "Copy" or "Cut". Next, position the cursor, select right mouse for a menu, then left mouse to "Paste". That is three extra steps for a simple Copy and Paste, or two extra steps for a Cut and Paste.
This feature is called the primary selection, and it's supported by many Wayland compositors now. Should you choose to use wlroots, it's a single line of code to enable it.
These are the sorts of things normally provided by xrandr. Thus far, there is no "wrandr" utility. In the past, Weston has been hostile toward offers to provide such a utility. Weston supports setting modes on start-up, which works fine, but, for instance, kwin_wayland seems to have no way to set a correct mode when it defaults to a mode that does not work.
The problem with xrandr and Wayland is hinted to in the name: xrandr. These features are supported but through other means. There has been some interest in a protocol which could accomodate an xrandr-like-tool in the KDE and wlroots camps, but no one has pushed it forward. If you wanted to champion getting this standardized and took the initiative I think you'd find success.
I have yet to see any Wayland compositor or Wayland utility that will allow me to set the color gamma per output, where I run three screens and want the colors to match across the display.
This is supported by the protocol and by compositors implementing it, but clients have not caught up. Another place where you could easily extend this to meet your needs.
"Sway is tiling Wayland compositor" I don't mean to be rude, but I am not a tiling fan, and this is not what is commonly used with lxqt, which defaults to Openbox.
Additionally, for the present, there would have to be support for the Xwayland server, for backward compatibility.
I didn't understand the degree to which LXQt is involved with OpenBox today. I see what you mean now. I know waybox is based on wlroots and @WizBright has expressed interest in supporting the layer shell, so if you use that approach you will be able to run your shell on waybox. However, waybox is early in development and you should be prepared to help out if you want to go that route.
One thing to do towards wayland is to support panel positioning. I think in wayland protocol there is no common way to do so, and implementation differs across compositors. The second thing that I got stuck when trying to run LXQt components under wayland was lack of protocol to interact with virtual desktops, it seems that there is no such concept in wayland world and again it is compositor specific. Do you have any updates on that?
Check out the layer shell for panel positioning concerns. Regarding virtual desktops, there has been some discussion on this matter, but achieving consensus is proving difficult. Many different desktops implement the concept of "virtual desktops" quite differently and finding a protocol that adequately describes them all is difficult - waybox/OpenBox does it very differently from sway/i3, waymonad/xmonad, KDE, and so on. However, if you want to work at it we could probably figure it out. If not, a proprietary protocol between you and whatever compositor you use (be it waybox or something in-house) would suit your needs.
Just checked the latest Plasma wayland: QWidget::setGeometry() doesn't work. What a big regression!
@all - please cool down. I don't want this discussion political correct. But please let emotions out as far as possible - as they don't help solving technical problems. Another hint: It is not wise to tell a lead developer of LXQt that he has no saying in his own project. Let's just discuss facts, show the code. That really means: Show the code, don't show some repos and projects and say - oh, there are the repos and projects, you just have to write the missend code. That will not work. Beside of that we are happy to test and help - and my guess is that there will be contriutions over time from our side. Let's just see, what will happend.
Show the code, don't show some repos and projects and say - oh, there are the repos and projects, you just have to write the missend code. That will not work.
That's not what I'm here for. I have my own projects to tend to. If you guys want Wayland support then it's up to you to do it, and if you don't, then whatever, don't do it. Someone mentioned wlroots and I came here to reach out and offer our support and advice should you guys decide to work on this. That's all I'm here for.
@agaida Sorry that I got emotional but that's who I am when I see excuses after excuses disguised as features. The systemd disease is happening again but with bigger scales: wayland disease.
Since I can't help telling the bitter truth, I won't leave a comment here.
The systemd disease is happening again but with bigger scales: wayland disease.
@tsujan but we need to have support of those things in order to withstand gnome alien interface (IMHO) and a js disease of mainstream DEs in general.
Sorry to be off-topic here, but systemd is a good point. There was a time when i can't stand the mention of it. At one point it became usable, for us debian derivatives just over night. Still not perfect, but better than the situation before in the very most cases.
If that will happend with wayland i will be happy - it might be not tomorrow, but it will happend some day. At least i hope so. As i wrote before - that should not hinder us to be prepared. And i give a damn about some missed things if i can be sure that these things will be addressed. What i miss right now is the will of wayland upstream to clarify (and maybe implement) some protocol things, be nice about concerns of downstreams.
@technic: It's unlikely that gnome will switch to Qt - i would be at least a bit surprised, so no worry. Did i mention that we use glib2 in central points?
@agaida Sorry that I got emotional but that's who I am when I see excuses after excuses disguised as features. The systemd disease is happening again but with bigger scales: wayland disease.
Since I can't help telling the bitter truth, I won't leave a comment here.
Your "bitter truth" is a charade. You refuse to view this discussion without your lens of prejudiced, plainly incorrect ideas about how Wayland works for long enough to realize that you're talking to someone on your side of the debate. I hate systemd as much as you and what's "happening" to Wayland isn't.
Your attitude only serves to exacerbate the problems that you appeal to in your damnation of Wayland.
What i miss right now is the will of wayland upstream to clarify (and maybe implement) some protocol things, be nice about concerns of downstreams.
I am right here, trying to talk to you.