Tiny Core Linux
Tiny Core Extensions => TCE Talk => Topic started by: Vaguiner on October 13, 2023, 10:15:17 AM
-
Hello.
I've tried to use wayland several times on TinyCore and each time I failed. But whenever I see something related to Wayland on the internet I try again.
I know there are other related topics, but I personally believe that these are outdated. Maybe some administrator can teach us in a practical and concise way how to test wayland? And is there a less bloatware way to make it work?
What motivates me is the fact that several distributions are collectively abandoning Xorg. Xorg itself abandoned itself... And I worry about possibly being stuck with something that may contain vulnerabilities.
Relevant links:
https://www.phoronix.com/news/GNOME-MR-Drop-X11-Session
https://docs.fedoraproject.org/en-US/fedora/f34/release-notes/desktop/Desktop/#_kde_plasma_now_defaults_to_wayland
https://gist.github.com/probonopd/9feb7c20257af5dd915e3a9f2d1f2277
https://wiki.archlinux.org/title/wayland
-
i use tc specifically in order to avoid bloat like those common desktop environments that you're mentioning.
for a long time i used just Xvesa, no acceleration.
xorg is sadly very huge. but as long as wayland is so strongly integrated with all this freedesktop&dbus&systemd&pulseaudio stuff, i'm not overly motivated to play with it.
why don't you wait until X is actually abandoned? why maintain both things in parallel, for double the work?
i already maintain ipv4 and ipv6 here at my home... that's enough "transitions" at one time.
-
why don't you wait until X is actually abandoned? why maintain both things in parallel, for double the work?
It seems like something interesting to have functional in tiny core since in theory it is much lighter and faster than xorg, but the dependencies, as you say, are painful.
-
The weston wayland reference window manager works on CorePure64, piCore and piCore64 - see the weston info file.
There’s also the sway wm and, for full on bloat, gnome-session in CorePure64.
For me wayland is notably faster than x on piCore.
For interests sake I compiled fltk-1.4 with the wayland backend and recompiled various extensions wayland only to get a TinyCorePure64 equivalent at about 150% of the size of the x version, but with 3d acceleration.
-
For me wayland is notably faster than x on piCore.
I saw a comment on reddit stating something similar, but I didn't mention it because it seemed absurd.
Because of this efficiency, Wayland is faster (on RPI 4: 400 fps instead of 100) and consumes less resources.
Is it really 4x faster?
In this sense, yes, old computers with extremely limited resources may not benefit from wayland on tinycore, but small components like the raspberry pi (which, by the way, is what moves the tinycore forum the most, I even feel alone in the corepure64 session) They would definitely benefit a lot.
-
Have you tried weston on CorePure64?
-
Have you tried weston on CorePure64?
I've tried everything and every time I failed there were errors suggesting that it was a problem with Nvidia's proprietary drivers. But I will try again today.
-
Ah - nvidia, that complicates things - perhaps it’s a question of loading the correct nvidia kernel module..
-
The buzz around Wayland makes me nervous. Xorg does everything I need, plus my favorite WM (fluxbox) and many of my must-have apps are Xorg-only at this point. If Xorg were to disappear tomorrow, I'd be in a world of pain. But I do realize that someday I may have to switch. I just hope that day isn't soon ;D
It is some solace that as long as there is TCL, there is a way to run Wayland with as little freedesktop/systemd/other-ballast as possible.
I do have two questions for the TCL developers, if you'd be so kind:
1. If Xorg were to soon be officially abandoned by its developers (maybe it is already), but majority of applications can still run on it, what would be TCL's plans regarding Xorg? Keep using last release? Switch to TinyX or something similar? Too soon to tell?
2. I was surprised to see that weston depends on wayland-protocols as well as on Xorg-7.7-3d. If weston is a Wayland compositor and Wayland is meant to replace Xorg, why does weston depend on Xorg? Forgive me if this is a stupid question with an obvious answer.
-
If weston is a Wayland compositor and Wayland is meant to replace Xorg, why does weston depend on Xorg? Forgive me if this is a stupid question with an obvious answer
I endorse the question.
And it is also curious that xwayland does not have xorg as a dependency.
-
The buzz around Wayland makes me nervous. Xorg does everything I need, plus my favorite WM (fluxbox) and many of my must-have apps are Xorg-only at this point. If Xorg were to disappear tomorrow, I'd be in a world of pain. But I do realize that someday I may have to switch. I just hope that day isn't soon ;D
I looked into it and it seems fairly trivial to make a wrapper for a Wayland-only application to display in X. As far as I'm concerned that's all I need to know to be sure I can stick with X for as long as I want unless Linux gets completely redesigned from underneath it (which would be a much bigger disaster). I expect someone else will develop the wrapper before I need it too, although it looks like something I could do.
1. If Xorg were to soon be officially abandoned by its developers (maybe it is already)
It isn't abandoned, a new libX11 version was released this month. What can be confusing is that they stopped doing the old combined packages of all the separate libraries and programs and now release individual parts separately instead. It's also no longer a Freedesktop.org / Red Hat project which means fewer paid programmers are working on it. I always seem to get fed up with Freedesktop.org projects, I've even given up on Modem Manager now and had more success directly configuring pppd, so I'm tempted to consider this a good thing.
Here's the current release manager (https://www.patreon.com/p12tic/about), trying to raise money for himself.
-
1. If Xorg were to soon be officially abandoned by its developers (maybe it is already), but majority of applications can still run on it, what would be TCL's plans regarding Xorg? Keep using last release? Switch to TinyX or something similar? Too soon to tell?
We'd ship the last release as long as it works.
TinyX we already control, and runs most 2d apps anyway.
-
I was surprised to see that weston depends on wayland-protocols as well as on Xorg-7.7-3d. If weston is a Wayland compositor and Wayland is meant to replace Xorg, why does weston depend on Xorg? Forgive me if this is a stupid question with an obvious answer.
It depends on whether mesa is compiled against x, wayland or both. Since we want the choice of using x and wayland, mesa is compiled against both (except x86 where it’s only compiled against x).
As mentioned above, using fltk-1.4, it’s possible to make a wayland only version of TinyCorePure64.
-
Thank you, curaga and Juanito. Good to know.
Also, thank you so much for TCL. It is a gem and I'm glad it is in good hands :)
-
YES! Huge KUDOS & Thanks to curaga, Juanito, and Rich who are definitely priceless!
-
...
individual parts separately instead. It's also no longer a Freedesktop.org / Red Hat project which means fewer paid programmers are working on it. I always seem to get fed up with Freedesktop.org projects, I've even given up on Modem Manager now and had more success directly configuring pppd, so I'm tempted to consider this a good thing.
hahaha yes. been using pppd for a long time. since before modemmanager existed.
also AT commands and qmi and uqmi tools for 3G/4G modems, all manually, bec. each modem needs different quirks. for QMI i *tried* to use modemmanager, but it didn't work! :)
for wifi at first i also tried networkmanager, but it didn't work. bugs, performance issues, packet drops, impossible to debug.
so instead: for both ethernet and wifi: udhcpc (learned here from TC) with my own action script
and `wpa_cli -a actions.sh` with the same actions script for L1 events, in addition to link state events (from iproute2's `ip monitor`).
and wpa_supplicant, configured via the comfortable wpa_gui that ships with it.
even networkmanager hates networkmanager, so they use netplan now as a backend on the newest ubuntu (off-topic here i know, but probably worth the schadenfreude). at least that's editable in plaintext finally, it's much better than nm-cli now, which has a lot of unacceptable bugs that i keep running into on systems administered by others.
-
As mentioned above, using fltk-1.4, it’s possible to make a wayland only version of TinyCorePure64.
that's a relief, but my most important programs are aterm, urxvt, xterm ;)
-
Foot and havoc are described as minimal wayland terminal emulators, but I haven’t tried them.
-
havoc added to x86_64 repo
-
I gave weston a try on TCL14 x86_64. From the console, with a working network connection:
$ tce-load -wi weston xwayland aterm
$ XDG_RUNTIME_DIR=/run/user/$(id -u) weston-launchAfter that, weston starts successfully. It has a bar going across the top with an icon that, when clicked, causes the default terminal emulator (weston terminal) to launch successfully.
From weston terminal I'm unable to launch aterm or any other application that requires X. Error each time is some variation of "display :0 not found".
Please, in addition to loading xwayland, what else needs to be done in order for X applications to work in wayland (e.g., in weston)? Or will most applications that expect X not work with wayland?
(Pardon my ignorance--this is my first time ever not in an X session. I'm just kicking weston's tires at this point, to see if it would be a viable alternative to fluxbox if someday I were forced to "upgrade" to wayland.)
-
poked around and stumbled into this FAQ which mentions weston/libweston a few times.
https://wayland.freedesktop.org/faq.html
-
To use xwayland you need the following in ~/.config/weston.ini:
[core]
xwayland=true
[xwayland]
path=/usr/local/bin/Xwayland
Of course the idea is not to use xwayland, which is a little painfull as it means the tinycore helper gui applets don't work.
Note that all gtk3 apps will work without xwayland as it has a wayland backend - qt-5.x apps will probably work too.
Here's an example weston.ini without xwayland (the location of the adwaita icons may have changed): [launcher]
icon=/usr/local/share/weston/icon_terminal.png
path=/usr/local/bin/weston-terminal
[launcher]
icon=/usr/local/share/icons/Adwaita/22x22/legacy/accessories-text-editor.png
path=/usr/local/bin/gedit
[launcher]
icon=/usr/local/share/icons/Adwaita/22x22/legacy/system-file-manager.png
path=/usr/local/bin/nautilus
[launcher]
icon=/usr/local/share/icons/Adwaita/22x22/legacy/web-browser.png
path=/usr/local/bin/firefox
[shell]
num-workspaces=4
[keyboard]
keymap_layout=gb
[output]
name=HDMI-A-1
mode=1920x1080
-
Also useful: https://man.archlinux.org/man/weston-bindings.7.en
-
Note that all gtk3 apps will work without xwayland as it has a wayland backend - qt-5.x apps will probably work too.
Hi Juanito. Thank you for sharing this very useful information. It will provide some pain relief.
brave-browser is a gtk3 app, so I guess it should work in wayland. This is what I see in weston, without xwayland, using the default terminal emulator:
$ sudo /usr/local/etc/init.d/dbus start
$ brave-browser
[9170:9170:1020/092545.448733:ERROR:ozone_platform_x11.cc(240)] Missing X server or $DISPLAY
[9170:9170:1020/092545.448763:ERROR:env.cc(255)] The platform failed to initialize. Exiting.
Any idea how to fix?
-
Also useful: https://man.archlinux.org/man/weston-bindings.7.en
Thank you for that. I found this for custom keybindings: https://github.com/tarvi-verro/weston-binder
Do you think it would be useful to include this module in the weston extension?
-
$ brave-browser
[9170:9170:1020/092545.448733:ERROR:ozone_platform_x11.cc(240)] Missing X server or $DISPLAY
Any idea how to fix?
Hi Juanito. The fix in this case turned out to be easy:
$ brave-browser --ozone-platform=wayland
-
I'm going to set a TCL instance aside for wayland testing, using its reference compositor. But weston depends on Xorg-7.7-3d and X starts automatically, which is inconvenient in this setting.
What's the most proper (i.e., TCL-idiomatic) way to prevent X from starting automatically?
-
You can use the boot code “text”.
-
You can use the boot code “text”.
Hi Juanito. That's exactly what I was looking for. Thank you very much.
-
weston has been updpated in the x86_64 and aarch64 repos.
weston-launch has been depreciated, so the new way to start weston is: sudo -- seatd -g staff -n /run/seatd.sock & XDG_RUNTIME_DIR=/run/user/1001 weston
-
weston has been updpated in the x86_64 and aarch64 repos.
Thank you, Juanito. Do you know how to configure weston so that it shows a window list (known as "iconbar" in fluxbox--screenshot here (https://gnuser.ddns.net/public/iconbar.jpg)) on its panel? I find it difficult to use a stacking window manager without a window list/iconbar.
-
I don’t know of an icon bar that works in weston - you can use super+tab to switch between windows.
-
I don’t know of an icon bar that works in weston
I feared as much. Thanks for confirming.
you can use super+tab to switch between windows.
For testing purposes that will do just fine. Thanks again :)
-
I submitted labwc (https://github.com/labwc/labwc) for the x86_64 repo.
labwc does not come with an icon bar but, since it is wlroots-based, it could eventually be used with waybar (https://github.com/Alexays/Waybar). Getting waybar into the repo would not be trivial because some of its dependencies need to be added to the repo first.
-
Of course the idea is not to use xwayland, which is a little painfull as it means the tinycore helper gui applets don't work.
Note that all gtk3 apps will work without xwayland as it has a wayland backend - qt-5.x apps will probably work too.
I've been running labwc in pure wayland environment. I recently discovered, to my surprise, that gtk2 apps and tc helper gui applets (e.g., mnttool, apps) work just fine. It turns out that labwc wraps applications in Xwayland as needed--automatically and without any special configuration.
When I run labwc, Xwayland is not normally running in the background (i.e., pgrep -fa Xwayland returns no hits). But after running and closing a gtk2 or fltk app, I find that Xwayland is running:
$ pgrep -fa Xwayland
7642 Xwayland :0 -rootless -core -terminate -listenfd 27 -listenfd 28 -displayfd 61 -wm 58I find labwc's no-hassle, Xwayland-only-when-needed approach to make a lot of sense. Discovering this made my day :)
-
That’s good to know.
As I think was mentioned earlier, fltk-1.4 has a wayland backend so the applets work (except where the accompanying script has something x specific).
-
Hi curaga and Juanito. Can you think of any reason to load xf86-video-intel.tcz when running wayland? Could it possibly help applications running inside Xwayland? When I remove it from onboot.lst and boot into wayland+labwc, everything seems okay (including gtk2 applications running in Xwayland).
I've been loading xf86-video-intel.tcz ever since curaga recommended it here (https://forum.tinycorelinux.net/index.php/topic,23085.msg144417.html#msg144417) but I'm not sure if the advice applies to wayland/Xwayland. Please enlighten me, as my understanding of graphics is very limited.
P.S. On a totally unrelated note, it seems weston.tcz.dep is missing dbus.tcz (dbus is needed to start weston).
-
Tu é BR? Vi esses dias seu nome "Bruno Dantas" em algum tcz, não me lembro qual. Isso é bem nome BR.
-
Sou americano mas nasci no Brasil, sim, e falo português em casa com meus filhos ;D
-
xf86-video-intel only affects Xorg. Xwayland always uses glamor 3d acceleration.
-
P.S. On a totally unrelated note, it seems weston.tcz.dep is missing dbus.tcz (dbus is needed to start weston).
Are you saying that weston has a missing dependency on dbus or that the dbus daemon needs to be running?
-
xf86-video-intel only affects Xorg. Xwayland always uses glamor 3d acceleration.
Hi curaga. Thank you very much for educating me about this.
Hi Juanito. Weston has a missing dependency. dbus.tcz should be added to weston.tcz.dep.
(It is also true that dbus daemon needs to be running, but user should know that if they follow your instructions in weston.tcz.info :) )
-
I just checked on both x86_64 and aarch64 and weston starts without dbus being loaded - as mentioned in the info, dbus can optionally be used with gtk3/dconf.
-
Oops. You are correct, of course. Sorry for the noise. weston.tcz.dep is fine as-is.
P.S. On a few occasions I got an error about dbus not being available when I tried to start weston, but that's only because I go the gtk3/dconf route 100% of the time. If user doesn't need gtk3/dconf, then no need for dbus (weston.tcz.info does explain both ways of starting weston.)
-
To fellow users: Don't run GUI applications as root.
But if you must run GUI applications as root, here's how to do it in wayland ;)
For Xwayland applications, you need to run this once per boot:
$ xhost +SI:localuser:rootThen, for example:
$ sudo gpartedFor wayland-native applications, create this wrapper script and give it a nice name. I went with gksudo:
#!/bin/sh
exec sudo WAYLAND_DISPLAY="$XDG_RUNTIME_DIR/$WAYLAND_DISPLAY" XDG_RUNTIME_DIR="/run/user/0" "$@"
Then, for example:
$ gksudo foot
I noticed that /run/user/0 does not need to exist. Maybe setting XDG_RUNTIME_DIR in gksudo is not actually necessary. I'm still learning.
P.S. The above is probably terrible for security. Use at your own risk. I post it here because it was hard to figure out and I needed this for rare situations.
-
P.P.S. It's better to use gksudo for Xwayland apps as well. This way, if the Xwayland app tries to launch a wayland-native app, it will work.
-
Ah - nvidia, that complicates things - perhaps it’s a question of loading the correct nvidia kernel module..
The problem really is with the drivers. I suppose this is because I decided to migrate absolutely everything into /usr/local. All the work that coreplayer2 had to do in the previous nvidia tcz to remove existing libraries was really necessary. I'll look into creating nvidia tcz correctly.
I also found it at least curious to be able to run Wayland inside a x session, as if it were a simple window.
(https://i.imgur.com/u8jQXN3.png)