Wayland and BunsenLabs

Colonel Panic · 2024-05-30 15:34:36

hhh wrote:

Colonel Panic wrote:
Dedo has published an unfavourable report about Wayland on his website;
https://www.dedoimedo.com/computers/wayland-2024.html
From what he's said it looks like XOrg is still the better option. Anyone got any thoughts on this please?
This is completely up to the user's hardware, OS/DE and choice of apps, in my opinion.
I'm using GNOME and Hyprland Wayland sessions on Ubuntu Noble beta currently, and both are working flawlessly for me, and getting better all the time as upgrades continue to come in for the upcoming release of Noble later this month (GNOME session) and as Hyprland develops (git, built from source).
The main advantage of Wayland on my low-end Intel integrated graphics system is screen tearing, which is absolutely eliminated on Wayland but continues to persist on Xorg no matter how much I monkey with xorg.conf (more accurately, xorg.conf.d/20-intel.conf).
That said, Wayland development is ramping up exponentially, so running it on Debian Bookworm/BunsenLabs Boron is not going to give you the best results in terms of app compatibility and performance, again IMO.
As to Dedo's specific post...
He's running Wayland on KDE Plasma 6, which had a buggy release outside of the Wayland issues and only just started introducing a Wayland session by default, and it has a whole host of known issues...
https://community.kde.org/Plasma/Waylan … ant_Issues
I think it's disingenuous to make an assessment of the current state of Wayland using recently released Plasma 6. GNOME is a better session to install to test Wayland, as they've been using it as their default for longer and have been developing Wayland-native apps for longer.
Also, Dodo doesn't know what he's talking about in general. ...
https://www.dedoimedo.com/computers/bun … erium.html
BTW, I tested the KDE Neon Plasma 6 live ISO that Dedo mentions, I thought it sucked as well. But to say that "KDE/Plasma is a cornerstone of Linux" so Wayland sucks because it sucks on Plasma for him ATM, after only 7 hours of usage... that sounds like clickbait to me, and I'm sorry I responded to it here!
Dedoimedo wrote:
Furthermore, I tested with Plasma 6 on top of KDE neon. Again, in part, the results here reflect the behavior of the KDE ecosystem as much as Wayland. Then, over the past decade, I've done 10s of similar tests, including all sorts of platforms, graphics and distros, including the entire gamut of desktop environments. The findings were often very similar, which gives me confidence that what I have here is indicative of the broader ecosystem. Furthermore, it doesn't matter. The findings were very similar on both machines. On top of that, KDE/Plasma is a cornerstone of Linux, and if things don't work there, then the problems cannot be sidelined or ignored.
This paragraph is a hot mess, take his opinions with more than a grain of salt.

Fair points all.

micko01 · 2024-06-07 21:43:00

johnraff wrote:

Is the package source code up somewhere? I'd be happy to take a look.

labwc-menu-generator

Since then I added a manpage, which keeps debian happy

---

Right now I'm running pure trixie on a new (to me - dell optiplex 7060 sff -dells nearly always work ootb on linux without chasing down obscure firmware) desktop machine, new dev box.

micko01 wrote:

The HP works fine but on logout trying to login again gets stuck in a loop. Only work around is to login to tty after a reboot. No such issue on the Acer, it's running sweetly.

Unfortunately this issue occurs with lightdm on the new machine too so I now have greetd running with wlgreet with labwc as the starter for for wlgreet.

debian/trixie have sway as a hard dependency of wlgreet which I should report as a bug as it will work with any wayland compositor which supports the layer-shell protocol (a special protocol for which I wont go into detail right now). I think I'll report this as a non-life threatening bug

The next step is to get nwg-hello (screenshot) working correctly as this one checks for sessions in /usr/share/xsessions and /usr/share/wayland-sessions whereas the more spartan greeters have to be hard coded to the command you want to run at login - hardly user friendly.

micko01 · 2024-06-07 22:01:32

@johnraff I also notice that in at least 1 of the bunsenlabs github repositories that you have created a 'Carbon' branch.

micko01 · 2024-06-08 03:05:23

I have nwg-hello working well now

It even starts xsessions. I'm going to post my configs here for safe keeping.

/etc/greetd/config.toml all files must be owned by user _greetd and _greetd must be added to video group for graphical login. Apparently this can be cpoied to /etc/greetd/greetd.toml so it survives an upgrade.

[terminal]
vt = 7

[default_session]
command = "labwc --config-dir /etc/greetd/lab-config"
user = "_greetd"

/etc/greetd/lab-config/autostart - also owned by _greetd

# start nwg-hello - full paths not a requirement, just faster lookup
exec /usr/bin/nwg-hello; /usr/bin/labwc --exit

/etc/greetd/lab-config/rc.xml - this is entirely unecessary but how else was I going to get a screenshot!

<?xml version="1.0" ?>
<labwc_config>

  <keyboard>
    <default />
    <keybind key="Print"><action name="Execute" command="grim" /></keybind>
  </keyboard>

</labwc_config>

diffs for nwg-hello

--- nwg-hello-default.css	2024-04-28 21:12:48.000000000 +1000
+++ nwg-hello.css	2024-06-08 10:12:23.652097801 +1000
@@ -1,5 +1,5 @@
 window {
-	background-image: url("/usr/share/nwg-hello/nwg.jpg"); background-size: 100% 100%
+	background-image: url("/etc/nwg-hello/labwall0-1920x1080.jpg"); background-size: 100% 100%
 }
 
 #form-wrapper {

--- nwg-hello-default.json	2024-04-28 21:12:48.000000000 +1000
+++ nwg-hello.json	2024-06-08 11:10:55.682552395 +1000
@@ -17,7 +17,7 @@
   "gtk-theme": "Adwaita",
   "gtk-icon-theme": "",
   "gtk-cursor-theme": "",
-  "prefer-dark-theme": true,
+  "prefer-dark-theme": false,
   "template-name": "",
   "lang": "",
   "env-vars": []

IMHO this is an almost drop-in replacement for lightdm and lightm-gtk-greeter

johnraff · 2024-06-08 03:31:21

micko01 wrote:

I have nwg-hello working well now
...
IMHO this is an almost drop-in replacement for lightdm and lightm-gtk-greeter

Nice!

micko01 wrote:

micko01 wrote:
This weekend I've spent leaning debian packaging, and as you probably well know a weekend barely scratches the surface!
I did manage to build and package labwc-menu-generator
johnraff wrote:
Is the package source code up somewhere? I'd be happy to take a look.
labwc-menu-generator

Well, I meant the Debian package source code, which would include instructions as to how to build the package and/or where files should be installed, along with info on package dependencies, version number, copyright, etc etc, all of which would be inside a debian/ subfolder. So dpkg-buildpackage, dbuild, pbuilder or whatever can build an installable .deb file from it.

Fact is, it would be quite nice to have somebody else working on BL Debian packaging...

micko01 wrote:

@johnraff I also notice that in at least 1 of the bunsenlabs github repositories that you have created a 'Carbon' branch.

Yes I've started migrating packages into Trixie format, and uploading them to a newly created Carbon apt repo. Only a couple so far, and very little change from Boron at the moment anyway. That will come in due course.

hhh · 2024-06-10 04:01:29

LINE EDITED BY JR: I've already done some backports, so [Debian packaging] seems like something I could handle. Start a new thread for this?

REPLY FROM JR: I've started a new topic here: https://forums.bunsenlabs.org/viewtopic.php?id=9010

---
Regarding labwc/nwg, I'm really struggling with it. Time for some basic tutorials in this dev forum to get us testers involved?

Also, I've managed to document installing and building Hyprland on a debian sid netinstall. Is anybody interested in a thread on that for using a tiling compositor on Wayland, as an alternative to a stacking one like labwc? There would be a lot of overlap in setting up peripherals like a display manager, launcher, panel, etc... so it might be beneficial to everyone interested.

Pic or it didn't happen...

As you can see, this setup has a long way to go still, but that's the kind of opportunity for documenting the process that would help everyone.

---
As to Hyprland, I need to do a new install to double check my steps and create a working tutorial, will do (but in no hurry so as to get it right.)

Last edited by johnraff (2024-06-11 04:34:20)

johnraff · 2024-06-11 02:43:06

hhh wrote:

Regarding labwc/nwg, I'm really struggling with it. Time for some basic tutorials in this dev forum to get us testers involved?

Would be very nice but please don't look at me! I haven't had any time to look at Wayland stuff at all, but maybe some of our other members who have been, could write something for beginners to get started?

Also, I've managed to document installing and building Hyprland on a debian sid netinstall. Is anybody interested in a thread on that for using a tiling compositor on Wayland, as an alternative to a stacking one like labwc? There would be a lot of overlap in setting up peripherals like a display manager, launcher, panel, etc... so it might be beneficial to everyone interested.

I think it would be most welcome, even if we don't ship a BL with tiling at this point. As you say, lots of useful info anyway.

Pic or it didn't happen...
https://i.imgur.com/RUdwgDct.png
As you can see, this setup has a long way to go still, but that's the kind of opportunity for documenting the process that would help everyone.

I think it would. And maybe encourage les autres to write up their work too.

johnraff · 2024-06-14 09:00:28

This blog post is from Nov. 2022 but readable, and fairly detailed about moving to Wayland - might be interesting:
https://anarc.at/software/desktop/wayland/

malm · 2024-06-14 21:23:52

Wow! Had missed this thread.

I think we've reached a 'soft' tipping point in the last six months whereby it's now a good time to start building a cohesive system under Wayland with small, independent components - targeted for users who have previously enjoyed BunsenLabs/LXQt/Xfce/RPiOS with X.Org.

The compositor (labwc) itself has been stable for longer and if my "family computer" had needed an overhaul I would have probably installed labwc on it at any time in the last year.

Did you see the release video from mid-May? https://youtu.be/gNIj6VU-IH8

Assume you've looked at https://labwc.github.io/integration.html

We (myself + other labwc maintainers) have collaborated quite a bit with people form LXQt, Xfce and RPiOS over the last 12 months (which has been a real delight). Those three teams have now got a lot of their desktop components in a Wayland ready position. For example I'm personally using "xfce4-panel" and "pcmanfm-qt --desktop" running natively under Wayland. Working with them has also resulted in us adding "--merge-config" to allow distros to make system wide changes in /etc/labwc/rc.xml whilst still allowing the usual user-config in ~/.config/labwc; and "--session" in support of lxqt-leave and similar.

My advice:

1. As a general rule, don't try to use/port X.Org desktop components on Wayland, for example tint2 and jgmenu. I think it's great that Xfce/LXQt have added Wayland support to their panels/desktops/etc, but for us I'd recommend a cleaner/simpler "reset" where possible.

2. Don't expect things to be like-for-like. Accept that it'll only be 90+% the same, but don't hang out for 99.9%. Don't say: "...but on X.Org we do this". If you log into Ubuntu, I'd say that an end-user couldn't easily tell if they're on X.Org and Wayland, but I expect it's taken a lot of work to grind out the last few percent.

3. When you stumble on things that aren't yet supported (e.g. <theme><titleLayout> and workspace control from panels), don't get frustrated if it takes a long time to get them implemented. The priority will always be bug fixes, refactoring, stability and tidiness.

https://github.com/johanmalm/roadmap/bl … hedule.png
https://github.com/johanmalm/roadmap/is … 1901685074

4. Don't feel in a rush. Just have fun :smile: You can just run labwc nested under openbox if you just want to try setting up a panel + background, etc. Suspect you'd be up and running in 20 minutes. But once you go across on the metal (from TTY) it is addictive. I went across four years ago and have rarely logged back into an X.Org session.

5. Don't be put off by some of the complex "sessions" that you might see in some setups. It should be enough to just install labwc/kanshi/mako/swayidle/swaybg/swaylock/xdg-desktop-portal-wlr and then populate your rc.xml, autostart, environment and menu.xml. There isn't really anything else to it for a simple setup, so running the two in parallel should be simple (with the Wayland session in 'beta' for as long as it's needed). I've never tried SDDM/GDM with Wayland, so have no comment on that.

6. I'd go with a clean rc.xml, autostart and environment. Just use the examples in docs/ https://github.com/labwc/labwc/tree/master/docs

7. Ponder the balance between only using upstream Debian packages vs developing some 'glue' and maintain some bespoke packages. For example, if Azote is deemed a good replacement for nitrogen, do we start maintaining a deb package? Or raspberry-pi's arandr fork.

https://github.com/nwg-piotr/azote
https://github.com/raspberrypi-ui/arandr

In terms of picking the right blend of clients and desktop components, that should be quite an enjoyable journey - and one that will be "defining" for BunsenLabs in the long term.

And @01micko - great to see you here. Didn't realise you were so active in the forums.

micko01 · 2024-06-14 22:34:31

^great that you dropped by @malm

Funny you mention azote because I have been working with Piotr to get it working as a 'proper' debian package for trixie here and also have his nwg-hello greeter working in a debian/trixie install as posted in labwc/discussions which you've seen going by the :+1:

I do have a base BunsenLabs netinstall working but it's too hacky to release right now because I'm installing stuff outside of apt but that will change in due course.

I've also a package and a debian recipe for labwc-menu-generator which I should post to labwc/discussions for safe keeping - bus factor . It also runs the t100[0/1].t tests sucessfully but has one compile warning which I'll look into and minimal lintian warnings. I should try to contact @b1rger (debian labwc maintainer) or post a bug report to debian itself to see if we can get it into debian testing.

I'll have to take a look at the raspberry-pi arandr fork. That sounds like something that will definitely fill a gap.

Thanks for the advice section. I'll be referring to that from time to time.

Bearded_Blunder · 2024-06-15 00:00:35

I'm trying to figure out why I should get excited about Wayland, currently I'm in "meh" land.
"It's the future" isn't going to do it for me.
So was Optane memory (nobody bought it), Risc (nobody bought it), Diesel engines for cars (except it turns out particulates), "lean burn" engines for cars (Except it turns out oxides of nitrogen), Airships (except it turns out weather), I could go on endlessly.

Persuade me, why go to the trouble? Actual advantages over X, which is mature & works.

I know it's new & shiny, that's unpersuasive so far.

So far as I can see, they both put a pretty GUI on the screen, otherwise exactly what?

Some advantage I can get my teeth into, I might buy it.

Last edited by Bearded_Blunder (2024-06-15 00:04:55)

johnraff · 2024-06-15 05:02:01

Hi @malm, thanks for visiting! If I have contributed relatively little to this conversation myself, it isn't because of lack of interest, but that other people seem to have it well in hand. The time I'd need to get up to speed would likely outweigh the value of what I might contribute (and there are plenty of other tasks I need to work on).

I do have some general questions, but I now see there's a "Discussions" section on GitHub - would that be the right place to ask about user/sysadmin issues? (Like, good choices for auxiliary apps, implementation of pipemenus...)

Anyway for now:

malm wrote:

...it's now a good time to start building a cohesive system under Wayland with small, independent components - targeted for users who have previously enjoyed BunsenLabs/LXQt/Xfce/RPiOS with X.Org.

I'm not yet sure what we can have for Carbon/Trixie, but eventually that transition will have to be made. For now, it would be nice to at least be able to offer a minimal "base" install of BL on Wayland, alongside our full-featured X-based system.

1. As a general rule, don't try to use/port X.Org desktop components on Wayland, for example tint2 and jgmenu. I think it's great that Xfce/LXQt have added Wayland support to their panels/desktops/etc, but for us I'd recommend a cleaner/simpler "reset" where possible.

Do you think a base system is now possible without having to resort to xwayland for some essential tool or other? That would be a nice target for us, even if many users will install xwayland anyway.

3. When you stumble on things that aren't yet supported, don't get frustrated if it takes a long time to get them implemented. The priority will always be bug fixes, refactoring, stability and tidiness.

I like jgmenu very much and was disappointed that it will be gone - in particular the ability to programmatically launch a menu from a script or launcher without resorting to emulating keypresses was for me a huge plus over the openbox menu. But I don't mind waiting for things like that, as long as they're in the pipeline.

Anyway, totally approve of the focus on stability first.

4. Don't feel in a rush. Just have fun

Yeah OK that's totally cool. But - unless I'm misjudging our user-base - BL's main job is to be a stable, solid base where users can get on with whatever they've got a computer for. Sure, easy - and fun - to tweak, but it should also be perfectly usable out of the box. As long as regular users don't see anything gained from Wayland*, and X remains viable, then that will have to be our main offering.
*Right now, I read a slight speed gain esp. on old hardware, and better support for multi-monitor setups.

At the same time, I know there are lots of reasons why Wayland is an improvement over X that developers are well aware of, and I still think a simple Wayland-based BL version, would be very interesting to put out, if it can be done with our small developer team.

7. Ponder the balance between only using upstream Debian packages vs developing some 'glue' and maintain some bespoke packages. For example, if Azote is deemed a good replacement for nitrogen, do we start maintaining a deb package? Or raspberry-pi's arandr fork.

In-house built Debian packages are something I've preferred to avoid if possible. (Right now we have dillo and a patched xfce4-power-manager.) Two reasons:
1) Security. Once we take a .deb under our wing we're responsible for keeping an eye out for security upgrades. The much larger Debian team do that for us with their packages.
2) Work. Again,our dev team is very small. I'm not sure if we can cope with maintaining more than one or two lightly-patched apps, as we have now. If the team grew in size and included some people who were comfortable with eg C and Python packaging, then maybe we could reconsider that.

In terms of picking the right blend of clients and desktop components, that should be quite an enjoyable journey - and one that will be "defining" for BunsenLabs in the long term.

Yes I see that vision, and it's how CrunchBang started too, I think.

In the long term, a Wayland-based BL would be exciting to work on, and an improvement for our users. I imagine some other lightweight desktops' teams might be having similar thoughts, but I haven't yet heard of any.

I wrote in the OP:

johnraff wrote:

Corenominal's CrunchBang did pretty much what I had been trying to do [for myself] with Openbox, but all set up, configured nicely, and good looking to boot.
Now, what I'm wondering is if there might be a need for a distrolette that does something like that on Wayland - for people who are eager to move into the future but don't feel up to diving into all the configuration right off. How about a bare-bones but good-looking system, set up ready to use out of the box so people could base their system on it?

Last edited by johnraff (2024-06-16 04:44:57)

hhh · 2024-06-15 18:04:21

johnraff wrote:

This blog post is from Nov. 2022 but readable, and fairly detailed about moving to Wayland - might be interesting:
https://anarc.at/software/desktop/wayland/

Firefox has defaulted to native Waland since version 121, according to the Arch wiki. I just checked on my sid/GNOME setup and there's no Xwayland process open with firefox running. So things have progressed quite a bit in the year and a half since that post.

malm wrote:

I've never tried SDDM/GDM with Wayland, so have no comment on that.

labwc starts just fine using gdm3, and assume it would with sddm as well.

Bearded_Blunder wrote:

Persuade me, why go to the trouble? Actual advantages over X, which is mature & works..

Leaving out client-side rendering and a leaner codebase, the "Oh, that looks way better!" for me was screen tearing on my Intel graphics laptop. No matter what I tried in /etc/X11/xorg.conf.d/20-intel.conf I couldn't eliminate tearing in Firefox and mpv. With Wayland it's non-existent.

On the other hand, @Dobbie03's Nvidia card refused to cooperate with Wayland, he ended up swapping it for an AMD (I think) so he could experiment with Wayland compositors.

Bearded_Blunder · 2024-06-15 22:47:45

hhh wrote:

for me was screen tearing on my Intel graphics laptop. No matter what I tried in /etc/X11/xorg.conf.d/20-intel.conf I couldn't eliminate tearing in Firefox and mpv. With Wayland it's non-existent.

Well I guess that might persuade me, my next (overdue) PC build will likely use integrated Intel graphics, not that I've had issues with the old stuff I generally run. Well, not since W98 era hardware & getting X to behave was a chore back then, & my skill level was zero.

For Windows & what I do there I could almost be persuaded by the Intel ARC discrete graphics cards, they look good value, but they're still looking problematic for Linux (I think there's a dodgy driver for 'Buntu LTS), & I'm still undecided if I'll run a Linux base on the box I'm planning & virtualise Windows or vice versa.

I kinda need both operating systems.

Firefox has defaulted to native Waland since version 121, according to the Arch wiki. I just checked on my sid/GNOME setup and there's no Xwayland process open with firefox running. So things have progressed quite a bit in the year and a half since that post.

When I was playing recently I noted that under sysvinit, Firefox fails to open a window in Gnome at all, even though the process runs, unless you switch from the default Wayland session to X.

Works in KDE with Wayland though... so who knows why?

Last edited by Bearded_Blunder (2024-06-15 22:48:45)

hhh · 2024-06-16 04:30:29

Bearded_Blunder wrote:

When I was playing recently I noted that under sysvinit, Firefox fails to open a window in Gnome at all, even though the process runs, unless you switch from the default Wayland session to X.

I can't speak to that, as I have had no problems using systemd, and don't plan on setting up sysvinit just because of some anti-Poettering bias.

johnraff · 2024-06-16 04:42:40

It's interesting to compare reactions to systemd and wayland:
*) systemd brings many tangible benefits for users but got heavy resistance from many developers
*) wayland brings minimal improvements for users - at least at the moment - but seems to have most developers on board

But anyway:

hhh wrote:

...the "Oh, that looks way better!" for me was screen tearing on my Intel graphics laptop. No matter what I tried in /etc/X11/xorg.conf.d/20-intel.conf I couldn't eliminate tearing in Firefox and mpv.

I haven't noticed any problems with my Intel graphics desktop. Inxi says about it:

Graphics:
  Device-1: Intel Xeon E3-1200 v3/4th Gen Core Processor Integrated Graphics
    vendor: Hewlett-Packard driver: i915 v: kernel arch: Gen-7.5 ports:
    active: VGA-1 empty: DP-1, DP-2, HDMI-A-1, HDMI-A-2 bus-ID: 00:02.0
    chip-ID: 8086:0412 class-ID: 0300
  Display: x11 server: X.Org v: 1.21.1.7 compositor: Picom v: 9.1 driver: X:
    loaded: modesetting unloaded: fbdev,vesa dri: crocus gpu: i915
    display-ID: :0.0 screens: 1
  Screen-1: 0 s-res: 1440x900 s-dpi: 96 s-size: 381x238mm (15.00x9.37")
    s-diag: 449mm (17.69")
  Monitor-1: VGA-1 model: BenQ E900W serial: <filter> res: 1440x900 hz: 60
    dpi: 90 size: 408x255mm (16.06x10.04") diag: 481mm (18.9") modes:
    max: 1440x900 min: 720x400
  API: OpenGL v: 4.6 Mesa 22.3.6 renderer: Mesa Intel HD Graphics 4600 (HSW
    GT2) direct-render: Yes

But I probably don't watch as many videos as you. Can you suggest some test that always brings out the tearing in your case?

hhh · 2024-06-16 04:52:20

Well, a basic screen tearing test on YouTube...

https://www.youtube.com/watch?v=SD-31Q2IgKU

But it really manifested itself on some, ahem, seven seas movies in my library. Godzilla vs. Destroyah has scenes where it was particularly noticeable and distracting.

Also, just scrolling down this forum sucks on xorg without messing with xorg.conf with my cheap, integrated Intel UHD graphics.

❯ inxi -G
Graphics:
  Device-1: Intel Tiger Lake-LP GT2 [UHD Graphics G4] driver: i915 v: kernel
  Device-2: Bison Integrated Camera driver: uvcvideo type: USB
  Display: wayland server: X.Org v: 23.2.6 with: Xwayland v: 23.2.6
    compositor: Hyprland v: 0.41.0-21-ga9d7befc driver: X: loaded: modesetting
    unloaded: fbdev,vesa dri: iris gpu: i915 resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: iris,swrast
    platforms: wayland,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 24.0.5-1ubuntu1
    renderer: Mesa Intel UHD Graphics (TGL GT2)

johnraff · 2024-06-16 04:59:33

OK that test video had some tearing near the bottoms of the columns especially as it got faster.
But I never see any problem scrolling the forum.

hhh · 2024-06-16 05:02:21

Yeah, YMMV. For me it's bad. The screen tears just scrolling down the main forum page without tweaks. Here's my inxi ouput on sid/GNOME...

~$ inxi -G
Graphics:
  Device-1: Intel Tiger Lake-LP GT2 [UHD Graphics G4] driver: i915 v: kernel
  Device-2: Bison Integrated Camera driver: uvcvideo type: USB
  Display: wayland server: X.Org v: 24.1 with: Xwayland v: 24.1.0
    compositor: gnome-shell v: 44.9 driver: dri: iris gpu: i915
    resolution: 1920x1080~60Hz
  API: EGL v: 1.5 drivers: iris,swrast
    platforms: gbm,wayland,x11,surfaceless,device
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: intel mesa v: 24.1.1-2
    renderer: Mesa Intel UHD Graphics (TGL GT2)

-edi- And, like I said, video rendering under Wayland is perfect.

johnraff · 2024-06-16 05:07:47

Well that looks like a plus for sure.

PS now I look for it, I can see a bit of breakage when scrolling pages on Firefox. Nothing really annoying though.

Last edited by johnraff (2024-06-16 06:56:39)

#81 2024-05-30 15:34:36

Re: Wayland and BunsenLabs

#82 2024-06-07 21:43:00

Re: Wayland and BunsenLabs

#83 2024-06-07 22:01:32

Re: Wayland and BunsenLabs

#84 2024-06-08 03:05:23

Re: Wayland and BunsenLabs

#85 2024-06-08 03:31:21

Re: Wayland and BunsenLabs

#86 2024-06-10 04:01:29

Re: Wayland and BunsenLabs

#87 2024-06-11 02:43:06

Re: Wayland and BunsenLabs

#88 2024-06-14 09:00:28

Re: Wayland and BunsenLabs

#89 2024-06-14 21:23:52

Re: Wayland and BunsenLabs

#90 2024-06-14 22:34:31

Re: Wayland and BunsenLabs

#91 2024-06-15 00:00:35

Re: Wayland and BunsenLabs

#92 2024-06-15 05:02:01

Re: Wayland and BunsenLabs

#93 2024-06-15 18:04:21

Re: Wayland and BunsenLabs

#94 2024-06-15 22:47:45

Re: Wayland and BunsenLabs

#95 2024-06-16 04:30:29

Re: Wayland and BunsenLabs

#96 2024-06-16 04:42:40

Re: Wayland and BunsenLabs

#97 2024-06-16 04:52:20

Re: Wayland and BunsenLabs

#98 2024-06-16 04:59:33

Re: Wayland and BunsenLabs

#99 2024-06-16 05:02:21

Re: Wayland and BunsenLabs

#100 2024-06-16 05:07:47

Re: Wayland and BunsenLabs

Board footer