Wayland and BunsenLabs

johnraff · 2024-06-22 06:19:35

Bearded_Blunder wrote:

johnraff wrote:
Possible name Beakerland? But that would need a version tag too - Beakerland-13 or Carbon-Beakerland or something...
I'd just tag (and possibly name) the "non-mainstream" one Element-Isotope were it me, you can carry that through right up to Neon & beyond, & if you want a shorthand for version numbering there's always the number of the less common isotope available as a suffix.

First - we're talking about the name of the experimental carbon/wayland repo here? Or the name of the branches that will run parallel to the 'carbon' github branches? Micko's new repo currently calls its suite "trixie", same as Debian. Without thinking too deeply about the implications, I guess that should work OK. After all, our backports repos use the same suite name as Debian, eg bookwork-backports, so that a user can install a BL backport with '-t bookworm-backports' and get access to any necessary libraries in the debian backports. And if Micko wants his repo to be useful to people on other systems than BL then a non-BL name makes sense.

Another issue is whether the experimental repo is automatically pinned at 100 like backports (needing a '-t ' option to install) or not. Versioning of packages is a surprisingly tricky subject in fact.

Carbon-13 would be a coincidentally nice name, given that the Debian release number of carbon/trixie is also 13, but might confuse some people for the same reason. The confusion would continue into Nitrogen, whose main isotope is 14. So while I agree "<element>-<something>" would likely be the least confusing name for our branches, maybe something as boringly vanilla as "carbon-wayland" might be the way to go?

johnraff · 2024-06-22 06:36:24

micko01 wrote:

While I do intend to post a bug about "Intent To Package bug on labwc-menu-generator", I do have to convince @malm to create a release for it first.
...Hopefully we can get a 'release' soon and I'll contact the debian/labwc maintainer @b1rger.

At that point you'll have two options:
1) upload your debianized package to debian-mentors and post a RFS (request for sponsorship) and hope b1rger picks it up. If you become the maintainer you'll be expected to stick with it for a while I guess.
2) ask someone on the Lab Wayland Compositor Team eg Birger Schacht to take it on. He's the uploader for a whole bunch of packages: https://qa.debian.org/developer.php?ema … debian.org

Bearded_Blunder · 2024-06-22 07:03:49

johnraff wrote:

First - we're talking about the name of the experimental carbon/wayland repo here? Or the name of the branches that will run parallel to the 'carbon' github package branches? Micko's new repo currently calls its suite "trixie", same as Debian. Without thinking too deeply about the implications, I guess that should work OK. After all, our backports repos use the same suite name as Debian, eg bookwork-backports, so that a user can install a BL backport with '-t bookworm-backports' and get access to any necessary libraries in the debian backports. And if Micko wants his repo to be useful to people on other systems than BL then a non-BL name makes sense.

All good points, really it's up to you guys, I'm just throwing bits of pasta at the wall here to see what, if anything, sticks.

Another issue is whether the experimental repo is automatically pinned at 100 like backports (needing a '-t ' option to install) or not. Versioning of packages is a surprisingly tricky subject in fact.

Indeed, & despite my sig, I avoid adding oddball repos for that very reason.

Carbon-13 would be a coincidentally nice name, given that the Debian release number of carbon/trixie is also 13, but might confuse some people for the same reason. The confusion would continue into Nitrogen, whose main isotope is 14. So while I agree "<element>-<something>" would likely be the least confusing name for our branches, maybe something as boringly vanilla as "carbon-wayland" might be the way to go?

Avoiding confusion I'm all in favour of. Nothing wrong with vanilla.

miko01 wrote:

Pid eins?
When that annoys I'll boot slackware, devuan or void. (runnit is actually pretty good).

I tend to stick with Debian, which makes runnit a little hard, lots of manual config I never got to grips with in Debian last time I looked. Though it's been a while.

johnraff · 2024-06-22 07:14:50

co-existence of BunsenLabs X11 and Wayland systems

Gnome (I've only briefly played with this to date) offer at login the choice of a Gnome Wayland session or legacy X11 session. I think it would be very desirable if BL were able to do the same, for users who want it. I can see some possible complications though:

1) Not everyone will want to install both openbox and labwc, along with all their associated utilities. Both X11 and Wayland setups have to be installable separately, and adding the other alternative to an existing system needs to be possible.

2) What install paths to provide? Right now, the netinstall script (see below) looks like a good option for experimental setups because apart from installing a list of packages it can easily be configured to directly copy in files and run arbitary commands before and after package install.

Iso files are the most comfortable install path for regular users though. I guess that means providing an X11 iso and possibly a Wayland iso too? Or even a Wayland+X11 iso, with options at install time? Even more, can a Wayland iso be made able to add a Wayland session to an existing X11 system? Or vice versa?

3) The login manager. I haven't looked into it but does GDM run on Wayland or X when it's putting up the greeter? If the login manager has to run on Wayland, then there's already a need for (a lot of?) Wayland libraries even if running X11 for the user session. OTOH can a login manager perhaps use xwayland before starting a wayland user session? Are there any examples of such hybrid setups in the wild yet?

4) Debian has things like the x-session-manager alternative and the /etc/X11/Xsession.d/* files to configure the X session. Presumably Wayland has something similar? Can both systems exist on the same machine?

5) Right now, the netinstall script expects to add a graphics stack on top of a base CLI install. If we want to enable installing a Wayland session to exist along with an existing X session then some of the code will likely need looking at.

NOTE: The netinstall utility https://github.com/BunsenLabs/bunsen-netinstall
The carbon branch isn't ready yet. First I have to finish uploading the migrated carbon versions of the BL packages to their repo. It'll probably take a few more days at the rate it's going so far...

Then a carbon branch of the netinstall script will only be a few config file edits. When that's done, I'll make a "carbon-wayland" (or some other name) branch from that, that @micko01 can fork and make PRs to put together a BL-on-wayland installer.

Bearded_Blunder · 2024-06-22 09:37:34

johnraff wrote:

1) Not everyone will want to install both openbox and labwc, along with all their associated utilities. Both X11 and Wayland setups have to be installable separately, and adding the other alternative to an existing system needs to be possible.

I think everyone is likely to agree on that.

2) What install paths to provide? Right now, the netinstall script (see below) looks like a good option for experimental setups because apart from installing a list of packages it can easily be configured to directly copy in files and run arbitary commands before and after package install.

It certainly seems the easiest way to tweak & play to work out what's needed, once you have what's needed in that you've basically got the depends list for a metapackage in the script package lists.

Iso files are the most comfortable install path for regular users though. I guess that means providing an X11 iso and possibly a Wayland iso too? Or even a Wayland+X11 iso, with options at install time? Even more, can a Wayland iso be made able to add a Wayland session to an existing X11 system? Or vice versa?

For a netinstall, & possibly a full offline installer (don't see why not, assuming all the requred debs are in the iso's repo), it's perfectly possible to install the base system, pop up a question from late_command in the preseed, & then carry on to install matapackage(s) appropriate to the response given.

It's my intention to demo that sometime, however, I have a broken Domain Controller that needs attending to before I can restore other VMs. Once there the broken mail-server is quite high on the list, as is the backup server for UrBackup. I do intend to get there though.

Anyhow, if wayland & x metapackages can be built which don't conflict, & can be installed alongside each other & in either order, it looks entirely possible to me to do from one iso.

3) The login manager. I haven't looked into it but does GDM run on Wayland or X when it's putting up the greeter? If the login manager has to run on Wayland, then there's already a need for (a lot of?) Wayland libraries even if running X11 for the user session. OTOH can a login manager perhaps use xwayland before starting a wayland user session? Are there any examples of such hybrid setups in the wild yet?

Looking at the listed depends on gdm3 for Trixie, it appears to depend on X. I'd look at the deps on gnome-session to see if that can provide the needed x-session-manager using wayland or x-wayland without x, only the package search results for all the gnome session related stuff here are returning "Server Unavailable" errors here at the moment.

4) Debian has things like the x-session-manager alternative and the /etc/X11/Xsession.d/* files to configure the X session. Presumably Wayland has something similar? Can both systems exist on the same machine?

Above my pay grade, sorry, someone else might know.

5) Right now, the netinstall script expects to add a graphics stack on top of a base CLI install. If we want to enable installing a Wayland session to exist along with an existing X session then some of the code will likely need looking at.

Also above my pay grade, but seems likely. Also seems likely you'll eventually want the option to install an X session alongside a potentially pre-existing Wayland one, or both sessions on top of a CLI install...

A later "one size fits all" branch, as it were.

NOTE: The netinstall utility https://github.com/BunsenLabs/bunsen-netinstall
The carbon branch isn't ready yet. First I have to finish uploading the migrated carbon versions of the BL packages to their repo. It'll probably take a few more days at the rate it's going so far...

They are appearing though, that's the main thing. Sorry I'm no help with that. Snowed under at present, & off to accompany Mother to hospital for her follow-up or an ECG (something) shortly.

Then a carbon branch of the netinstall script will only be a few config file edits. When that's done, I'll make a "carbon-wayland" (or some other name) branch from that, that @micko01 can fork and make PRs to put together a BL-on-wayland installer.

Sounds like a plan.

hhh · 2024-06-23 03:53:35

Bearded_Blunder wrote:

johnraff wrote:
3) The login manager. I haven't looked into it but does GDM run on Wayland or X when it's putting up the greeter? If the login manager has to run on Wayland, then there's already a need for (a lot of?) Wayland libraries even if running X11 for the user session. OTOH can a login manager perhaps use xwayland before starting a wayland user session? Are there any examples of such hybrid setups in the wild yet?

I have to go through the last couple of pages of posts, there is a lot of info and a lot of questions, and some of it should be split into individual threads (nwg-hello, for one).

Anyway, I'm running labwc/gdm3 on sid and gdm3 in trixie/sid (and I think bookworm too) uses gdm-wayland-session by default. To get gdm3 to use Xorg, you have to edit /etc/gdm3/daemon.conf and un-comment this line...

[daemon]
# Uncomment the line below to force the login screen to use Xorg
#WaylandEnable=false

... and reboot.

Installing gdm3 with no-recommends brings in gnome-session-bin, gnome-session-common, gnome-settings-daemon and gnome-shell. None of those provide a login option to a GNOME session. You have to install gnome-session for that (/usr/share/wayland-sessions/ and /usr/share/xsessions)...

https://packages.debian.org/trixie/all/ … n/filelist

Anyway, I'm pretty positive you can still start a GNOME Wayland session even if you're running gdm3 in Xorg mode. I can test it later if need be (I'll have to install gnome-session again). I assume you can start labwc and openbox from that setup as well.

Unlike using greetd, which doesn't execute a *.desktop file at all, as far as I can tell. @micko01 hopefully knows more about this than I do.

hhh · 2024-06-23 04:08:08

Anyway, I think we should just release Carbon with Openbox/Xorg and let all the Wayland stuff be experimented with via threads like this one, with tutorials and scripts and whatnot being added as time allows and as Wayland projects progress.

johnraff · 2024-06-23 04:27:34

@hhh thanks for shedding some light.

hhh wrote:

Anyway, I'm running labwc/gdm3 on sid and gdm3 in trixie/sid (and I think bookworm too) uses gdm-wayland-session by default. To get gdm3 to use Xorg, you have to...

So it runs on wayland by default, but it can be configured to use X. I guess if we want users to have optional access to both X and W then a certain number of extra libraries is inevitable. It might not be hugely wasteful though.

Installing gdm3 with no recommends brings in...
None of those provide a login option to a GNOME session. You have to install gnome-session for that.

That makes sense if we regard GDM's job as being a display manager and not specifically a gatekeeper for GNOME. And that suits our purposes, if we choose GDM as our replacement for lightdm in Carbon, that is. There are a couple of other options - SDDM and greetd at least.

(/usr/share/wayland-sessions/ and /usr/share/xsessions)...

Two parallel systems - if both can co-exist we should be OK.

Anyway, I'm pretty positive you can still start a GNOME Wayland session even if you're running gdm3 in Xorg mode. I can test it later if need be (I'll have to install gnome-session again).

Interesting. Then presumably gdm3 in W mode can launch an X11 session too.

It doesn't look as if the display manager is going to be a major show-stopper then. Whether we choose X11 or Wayland as default for Carbon, we want to make it as easy as possible for our users to switch to the other one, preferably without having to do the install all over again.

johnraff · 2024-06-23 04:35:12

(cross-posted here)

hhh wrote:

Anyway, I think we should just release Carbon with Openbox/Xorg and let all the Wayland stuff be experimented with via threads like this one, with tutorials and scripts and whatnot being added as time allows and as Wayland projects progress.

Unless things change dramatically between now and Trixie release (1 more year?) then that makes sense. Let's do our utmost to get a Carbon release out pretty much in sync with Debian this time.

It should be quite possible as long as we don't try to add any new features (I have none in mind right now). And maybe it's not too early to start thinking about the Carbon graphics stack? Boron is so pretty and popular it will be a hard act to follow...

At the same time if there are things we can do in the Carbon X session context to smooth the Wayland transition down the line, now would be a good time to think about them. For example, unless lightdm looks likely to start supporting Wayland soon, then a display manager switch to gdm3 could be a candidate?

johnraff · 2024-06-23 05:05:12

co-existence of BunsenLabs X11 and Wayland systems, part 2 - Packages

I forgot to put this in post 149

Thinking about the bunsen packages - at first I was wondering if a lot of them might need to have two versions bunsen-something-wayland and bunsen-something-x, which wouldn't be comfortable at all, especially if they were mutually exclusive. But that might not be necessary. It's very easy for a script to test if it's running on W or X, so for example, if any of the pipemenus in bunsen-pipemenus couldn't work on Wayland (with labwc presumably) they could just exit out. Then as adaptations came in, bunsen-pipemenus would be updated and more of them would work on labwc. A quick glance at labwc's menu suggests it's very much like the openbox menu, so pipemenus that output that kind of xml have at least a good chance of working right off.

I'll have to rewrite those native jgmenu csv pipemenus I wrote though, back into xml. Not super-thrilled about that to be honest, but can't be helped.

Other packages that come to mind are the conky and tint2 utilities which would have to be gone over and all the x-utility (xdotool, xwininfo etc etc) calls replaced with something else. Well, tint2 will almost certainly not show up in Wayland, so could be gone in Carbon anyway (replaced by xfce4-panel? something else?) which would save having to work on tint2 manager and friends.

So even if Carbon gets no major new features, it could be a good time to consider some possible package substitutions.

BLOB is a huge glob of shell scripting with again many calls to x-things, but luckily it is quite modular, so it might turn out to be possible simply to have it test and disable sections which don't work on Wayland, leaving only the bits that do. That would allow incremental improvement as developer time allowed - as with the pipemenus.

The BL package that looks trickiest is perhaps bunsen-configs. Again, at first I was thinking it might need to have two mutually incompatible variants bunsen-configs-w and bunsen-configs-x, but that would make simple session switching at login time impossible. Much nicer would be a single package which held all the necessary configs for both W and X sessions, the way we already ship configs for different terminal emulators for example. That will need some research...

johnraff · 2024-06-23 05:13:45

johnraff wrote:

Iso files are the most comfortable install path for regular users though. I guess that means providing an X11 iso and possibly a Wayland iso too? Or even a Wayland+X11 iso, with options at install time? Even more, can a Wayland iso be made able to add a Wayland session to an existing X11 system? Or vice versa?

Thinking about how iso files usually work, while an install-time dialogue offering W, X, or W+X might well be possible, I've never heard of an iso booting up and offering to add something to an existing system! Is there such an animal? If not, I guess it would have to be the netinstall script.

hhh · 2024-06-23 05:20:42

johnraff wrote:

Then presumably gdm3 in W mode can launch an X11 session too.

gdm3 runs in Wayland by default now and a standard GNOME install provides 4 session options... GNOME on Wayland, GNOME on Xorg, and GNOME Classic on both Wayland and Xorg, so yes!

johnraff · 2024-06-23 05:26:41

^so there is hope.

micko01 · 2024-06-23 05:27:16

^I've tested a copule of older openbox pipe-menus and couple I've tried work OOTB on labwc; bl-places-pipemenu and bl-libreoffice-pipemenu. bl-multimedia-pipemenu won't take much fiddling.

There are some custom pipemenus for labwc here on github

johnraff · 2024-06-23 06:50:32

^bl-libreoffice-pipemenu and bl-multimedia-pipemenu are no longer used unfortunately. In fact they no longer exist, since Lithium.
The new install menu spits out jgmenu csv code so that will have to be rewitten for labwc.
But it outputted XML in an earlier incarnation so it might not be too hard, and of course openbox on BL/X will happily use XML pipemenus.
(I've said it before, but I'm quite unhappy about losing jgmenu. I'm sure @malm had good reasons, but...)

Last edited by johnraff (2024-06-23 07:00:07)

micko01 · 2024-06-23 08:21:22

^still, it's handy that the native labwc menu at least supports pipemenus.

Working on the imgur-pipemenu now.

@malm does have trappist as you know but he is so busy with all the different projects under the `labwc` umbrella that he hasn't had the time for it.

trappist uses openbox menu syntax, so when pipemenu and icon support is eventually written my work on openbox_pipe_menu stuff won't be a waste of time

johnraff · 2024-06-23 09:42:25

I thought labwc already used openbox xml syntax for menus - not the case?

Shows how little I know about it...

micko01 · 2024-06-23 10:47:43

johnraff wrote:

I thought labwc already used openbox xml syntax for menus - not the case?
Shows how little I know about it...

It is the case! Labwc menus use openbox xml syntax. The only thing not supported is AFAIK <separator label=""/>, and that may change. Plain <separator /> is fine.

Sorry for misunderstanding.

Trappist, if it gets off the ground, will be prettier and have more features. We'll see what happens.

Bearded_Blunder · 2024-06-23 12:26:25

johnraff wrote:

johnraff wrote:
Iso files are the most comfortable install path for regular users though. I guess that means providing an X11 iso and possibly a Wayland iso too? Or even a Wayland+X11 iso, with options at install time? Even more, can a Wayland iso be made able to add a Wayland session to an existing X11 system? Or vice versa?
Thinking about how iso files usually work, while an install-time dialogue offering W, X, or W+X might well be possible, I've never heard of an iso booting up and offering to add something to an existing system! Is there such an animal? If not, I guess it would have to be the netinstall script.

Sounds about right. Though if someone already has W or X installed, apt install <other one's metapackage> would surely be the most comfortable way for most users.

johnraff · 2024-06-24 03:25:00

Bearded_Blunder wrote:

if someone already has W or X installed, apt install <other one's metapackage> would surely be the most comfortable way for most users.

Yes, that's true. But in these early days it's quite possible that some extra tweaking might be needed, that a script can do more easily. For now, it's very simple for developers to push a change up to the script on github without having to go through package upgrades.

#141 2024-06-22 06:19:35

Re: Wayland and BunsenLabs

#142 2024-06-22 06:36:24

Re: Wayland and BunsenLabs

#143 2024-06-22 07:03:49

Re: Wayland and BunsenLabs

#144 2024-06-22 07:14:50

Re: Wayland and BunsenLabs

#145 2024-06-22 09:37:34

Re: Wayland and BunsenLabs

#146 2024-06-23 03:53:35

Re: Wayland and BunsenLabs

#147 2024-06-23 04:08:08

Re: Wayland and BunsenLabs

#148 2024-06-23 04:27:34

Re: Wayland and BunsenLabs

#149 2024-06-23 04:35:12

Re: Wayland and BunsenLabs

#150 2024-06-23 05:05:12

Re: Wayland and BunsenLabs

#151 2024-06-23 05:13:45

Re: Wayland and BunsenLabs

#152 2024-06-23 05:20:42

Re: Wayland and BunsenLabs

#153 2024-06-23 05:26:41

Re: Wayland and BunsenLabs

#154 2024-06-23 05:27:16

Re: Wayland and BunsenLabs

#155 2024-06-23 06:50:32

Re: Wayland and BunsenLabs

#156 2024-06-23 08:21:22

Re: Wayland and BunsenLabs

#157 2024-06-23 09:42:25

Re: Wayland and BunsenLabs

#158 2024-06-23 10:47:43

Re: Wayland and BunsenLabs

#159 2024-06-23 12:26:25

Re: Wayland and BunsenLabs

#160 2024-06-24 03:25:00

Re: Wayland and BunsenLabs

Board footer