Closed psstoyanov closed 3 years ago
Thank you for your report. I'll test with other Wayland compositors.
Out of curiosity, is there a requirement for the wayland app to have references to a particular shell protocol?
I'm reading the following article from Lup Yuen Lee which is packed with interesting information: https://lupyuen.github.io/pinetime-rust-mynewt/articles/wayland Following the article and taking a look in the LVGL repo, I can't find any specific bindings to a particular shell protocol.
Out of curiosity, is there a requirement for the wayland app to have references to a particular shell protocol?
Your understanding is correct. The implementation is not good. Actually, the Wayland app doesn't use shell protocols, but has referenced it. Therefore, I'm going to refactor source files. (cc @Mai-Matsuura)
@psstoyanov I'm using Ubuntu 20.04 desktop. Can I install Plasma Wayland or Wayfire? Do they work on X11?
@HidenoriMatsubayashi , I don't know what is the state of Plasma Wayland with Ubuntu 20.04 and aarch64. Hopefully it is in good condition?
Yes, you can start the wayland sessions from X11 environment. If you go with Plasma Wayland - you can find the instructions on starting the session in their docs.
I would go with Sway or Wayfire as they are "easy" to handle if the distro repositories have broken or problematic builds with Plasma or Gnome. They are also significantly smaller (even building locally doesn't take unreasonable amount of time).
Both Sway (tiling) and Wayfire (stacking) require a configuration file or you will be presented with an empty view. You can keep those minimal with pretty much defining just shortcut to launch your preferred/installed terminal.
You can also disable Xwayland on Sway/ Wayfire easily though I don't know if this will be useful to you. Reference to the Xwayland flag for Wayfire here.
The example Wayfire configuration file provided in their repo: https://github.com/WayfireWM/wayfire/blob/master/wayfire.ini
This is my wayfire configuration file - there is plenty in it as I use it as my main DE on the PinebookPro.
Cage is tiny but I don't know if it will be flexible enough to use for this experiment - it is meant as a kios (though it could be a potential alternative to the weston-shell)
Note:
Thank you! I'll try that.
Forgot to mention something. Unlike Plasma Wayland, Sway and Wayfire are not full fledged desktop environments but compositors. The chances of breaking your test device setup are significantly smaller if go with one of them.
When I was experimenting with Gnome and Plasma side-by-side on the PinebookPro, I had to be extra careful about keeping them separate or some of the packages that handle the same functionality could cause hard to recover situations. Some references from the Manjaro's documentation on installing Desktop Environments here
Wayfire has lived alongside Plasma on my PinebookPro without causing conflicts for more than a year now.
Note: Both Sway and Wayfire use wlroots but they can be compiled with different versions with potential conflict when both are installed on the same system. It would be easier to go with just one of those instead of both.
@HidenoriMatsubayashi , can see the wayland-client now works with Plasma Mobile, Plasma Wayland and Wayfire :fire:
I can setup a few other images with different wayland sessions like Phosh, Gnome and so on if you would like some additional testing. Should the ticket be closed?
Thank you for your help! Yes, I'm glad if you would do some additional testing. After that, I'll update README to add a tested Wayland compositors list.
@HidenoriMatsubayashi , had the chance to check Lomiri and Phosh tonight. Both run with the Wayland client without a problem. Those 2 are in addition to Plasma Wayland, Plasma Mobile and Wayfire.
It's partially a guess but there will be some surprises with the display scaling setups on different DEs :smile: I'm sure Phosh runs with 200% scaling by default and it looks like Plasma Mobile does the same.
Switching to Lomiri, it mimicked 100% scaling on Phosh which would appear in similar size as the window visible on this image.
The desktop environment scaling on the device isn't connected to the embedder per-se but it could be good to know.
Tomorrow, I will load Gnome on one of the devices. If I can, I will try to take a look at SailfishOS or NemoMobile for the PinePhone.
Update:
3.38
with Wayland backed works as expected as well with the wayland client. Note: Whether the gnome wayland session will be used by default, depends on the distribution.Update 2:
Update 3:
[ERROR][linuxes_window_wayland.cc(660)] Xdg-shell is invalid
List of confirmed working environments with the Wayland client:
Known incompatible Wayland environment at the moment:
@HidenoriMatsubayashi , should I close the ticket?
The embedder is no longer bound to weston's shell protocols and the switch from wl_shell
to xdg_shell
has ensured compatibility with multiple environments. The only exception being GlacierUX which could be because the project is rather old (or the image I've used hasn't gotten that far). With every new or maintained Wayland environment, there was no issue.
Thank you so much! Your help is very helpful for us. I'll close this issue and update README later.
Update towards GlacierUX:
wl_shell
implementation - https://git.sailfishos.org/neochapay/lipstick/blob/nemo/src/compositor/lipstickcompositor.h#L23xdg_shell
: https://github.com/neochapay/lipstick-1
Thank you for your information.
@HidenoriMatsubayashi , small update on GlacierUX compatibility:
xdg_shell
removing the block from the side of GlacierUXflutter-client
running on GlacierUX: https://youtu.be/JRcDmSuby6sThank you so much. I've updated README.
At the moment using the standalone wayland client appears to be made to work only within a Weston environment. My attempts to use the embedder with other Wayland environments such as Plasma Wayland, wlroots based ones like Wayfire result in the following error:
I haven't attempted to run the embedder within Cage or Phosh but I don't expect different results.
From what I can see, this is because the defined shell protocol is specific to Weston's implementation: https://github.com/sony/flutter-embedded-linux/tree/master/src/wayland/protocol
Would using a different shell implementation like xdg allow for more Wayland environments to be supported? Or is the error given by the embedder a result from different check defined somewhere in linuxes_window_wayland.h?
From the Wayland book, I can see the section explaining on how to generate the C headers and glue code. Would experiments with other shell protocols be useful to the project?
My understanding isn't as complete as I would like it to be so I don't know if I'm just using the Wayland client incorrectly in this case.