Tiny Core Linux
General TC => General TC Talk => Topic started by: jconnor on March 18, 2011, 02:05:33 PM
-
I have watched some of the videos on Wayland. Looks pretty cool. Is that something that could eventually be used with TC?
-
Yes. It requires a KMS console and a recent mesa, so it might not run right now, but nothing's stopping it from running in the future.
-
Any update on Wayland?
The GNOME 3 Wayland session is really impressive, very smooth tear-free experience with much less lag than X11.
-
As per other topics, Wayland's size, runnable hw and dependencies preclude it from being included in the base. It does not exist as an extension currently since nobody was interested in making some - if you'd like to run it, please create the extensions.
-
'looks like santa came early this year - wayland posted to x86 and x86_64 repos
-
As per other topics
Which topics?
Wayland's size
Please name the size, ideally in comparision.
runnable hw
Wayland and Weston can be run with software rendering since v1.1:
http://www.phoronix.com/scan.php?page=news_item&px=MTI4MTE
http://www.phoronix.com/scan.php?page=news_item&px=MTM0Njg
and dependencies
Which dependencies?
'looks like santa came early this year - wayland posted to x86 and x86_64 repos
Thanks a lot "Santa" ;D :D :P ;).
Now we're still missing a compositor though, such as Weston for example:
https://wiki.archlinux.org/index.php/wayland#Requirements
;)
Could you possibly also add Weston (https://cgit.freedesktop.org/wayland/weston/) to the repo and upgrade gtk3.tcz to the latest version, since a current version of GTK+ 3 is required for Wayland:
https://en.wikipedia.org/wiki/Wayland_(display_server_protocol)#Toolkit_support
?
-
wayland becomes a dep of libEGL, which means libEGL extension grows in size (not such a big deal) and that X users get +/- 100kb of wayland extension they can't use.
The gtk3 extension is +/- current at 3.22.0 and it will compile against wayland. Compiling mutter with wayland support fails for me.
I suspect there will be a problem with libinput (required by wayland), the latest versions of this use the udev hwdb, which is not present in tinycore.
-
The gtk3 extension is +/- current at 3.22.0
Not in the x86 repo, which is at 3.14:
http://repo.tinycorelinux.net/7.x/x86/tcz/gtk3.tcz.info
and it will compile against wayland. Compiling mutter with wayland support fails for me.
I suspect there will be a problem with libinput (required by wayland), the latest versions of this use the udev hwdb, which is not present in tinycore.
See:
http://www.linuxfromscratch.org/blfs/view/systemd/gnome/mutter.html
Mutter Dependencies
Required
Clutter-1.26.0, gnome-desktop-3.22.0, libxkbcommon-0.7.0, UPower-0.99.4, and Zenity-3.22.0
Recommended
gobject-introspection-1.50.0, libcanberra-0.30, and startup-notification-0.12
Recommended (Required to build the Wayland compositor)
libinput-1.5.3, Wayland-1.12.0, wayland-protocols-1.7, and Xorg-Server-1.19.0 (with Xwayland). Additionally, Cogl-1.22.2, Clutter-1.26.0 and GTK+-3.22.4 need to be built with Wayland support.
;)
-
weston will run in a window under X without Xwayland and the weston terminal accepts keyboard and mouse input so perhaps the hwdb is not so vital after all.
-
Here's also a guide for Weston:
http://www.linuxfromscratch.org/blfs/view/systemd/general/weston.html
;)
-
Any update on Wayland?
The GNOME 3 Wayland session is really impressive, very smooth tear-free experience with much less lag than X11.
please show me how to introduce that "lag" visibly so i can reproduce this.
-
The GNOME 3 Wayland session is really impressive, very smooth tear-free experience with much less lag than X11.
please show me how to introduce that "lag" visibly so i can reproduce this.
Easy:
Start GNOME 3 @ X (with Mutter as the hardware accelerated compositing window manager incl. Vsync). Now open a window and place the mouse cursor on the window titlebar and click and hold the left mouse button and move the mouse around to move the window around. As you can see, the mouse cursor is faster than the window movement, i.e. there's some kind of input/rendering/drawing lag.
This will also be true and in many cases even worse than GNOME 3 with other X shells using compositing window managers. Take XFCE4 + Compton for example. Running XFCE4 with Compton results in proper VSync (unlike xfwm4). However, there's some huge input lag. In this case, the window movement is even much slower than the mouse cursor (compared to GNOME 3 @ X). So XFCE4 + Compton is an even better example.
In comparison:
Start GNOME 3 @ Wayland and do the same (i.e. move a window around). You will see that the mouse cursor and window movement is in perfect sync and it feels much less laggy and rock solid.
The same is also true for running Wayland @ Weston.
With Wayland there's no tearing and not such a lag as mentioned above. With Wayland it feels as good as with Windows Vista/7/8/8.1/10 @ DWM.
If you want to try out the GNOME 3 @ Wayland session, you can boot up the latest Fedora Rawhide live session:
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/
If you want to try out Wayland @ Weston, you can boot up the latest RebeccaBlackOS live session:
https://sourceforge.net/projects/rebeccablackos/
Let's hope that will stop you from posting pointless comments such as those:
what's the point of wayland?
it's a usual tactic i observe in open source projects: tell all slightly-related projects that the other competing projects are better. they don't look at why or care about any technicalities. they just think they do it for the greater good, that people will get back to work and then make more useful software (i.e. support their crappy feature request), cause all that was needed for greatness is their friendly encouragement.
:)
-
If you want to try out the GNOME 3 @ Wayland session, you can boot up the latest Fedora Rawhide live session:
https://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Workstation/x86_64/iso/
If you want to try out Wayland @ Weston, you can boot up the latest RebeccaBlackOS live session:
https://sourceforge.net/projects/rebeccablackos/
Looks like there's no live ISO in the Rawhide folder at the moment for some reason, so you can also simply use the live ISO of the latest release version, since Wayland is already the default for Fedora since Fedora 25 (http://www.phoronix.com/scan.php?page=news_item&px=Fedora-25-Released):
x86:
https://download.fedoraproject.org/pub/fedora/linux/releases/25/Workstation/i386/iso/
x86_64:
https://download.fedoraproject.org/pub/fedora/linux/releases/25/Workstation/x86_64/iso/
;)
-
Which topics?
Please do a search for "wayland".
Please name the size, ideally in comparision.
I am not going to do the work of making a Wayland iso. As you're the one interested in it, the onus is on you to do so. Without a comparable ISO there can't be byte-exact numbers.
Wayland and Weston can be run with software rendering since v1.1:
Yes. It still requires KMS, and more importantly, the *client* apps still require GL, ie mesa. There may be clients that can fall back to software rendering, but the majority will only support GL on Wayland.
Which dependencies?
KMS, libinput, mesa, others. I doubt you can get the lag-free experience using software rendering only.
-
Please do a search for "wayland".
I did (before posting here). Both via the forum search as well as via a well known search engine. And the only threads that came up did not discuss those topics, but see for yourself:
http://forum.tinycorelinux.net/index.php/topic,15228.0.html
http://forum.tinycorelinux.net/index.php/topic,16026.0.html
http://forum.tinycorelinux.net/index.php/topic,17361.0.html
:)
So, that being said, I used this thread to ask for an update, since it seemed to be the first thread on this forum where someone asked for Wayland.
Without a comparable ISO there can't be byte-exact numbers.
So, you're arguing without knowing the numbers...
I do not know the numbers either. But I guess it could still be kept quite small when using Weston instead of using a full fledged desktop environment. To quote freedesktop.org: "The Weston compositor is a minimal and fast compositor and is suitable for many embedded and mobile use cases." (https://wayland.freedesktop.org/)
Yes. It still requires KMS
And how's that an issue? Intel/AMD/NVIDIA hardware, they are all supporting KMS, at least with the open source drivers.
the majority will only support GL on Wayland.
Which Intel/AMD/NVIDIA hardware supports out of the box when using the open source drivers as far as I know.
KMS, libinput, mesa, others. I doubt you can get the lag-free experience using software rendering only.
I doubt software rendering is required when using open source drivers on Intel/AMD/NVIDIA hardware, which is probably being used by the majority of users in the (almost) year 2017 :).
-
pq: sorry for stealing you all this time you needed to insult me.
i'm trying to question my opinion, which is: wayland brings no advantage to my setup.
I didn't have noticeable lag when I moved windows in windows 95, and i don't have any annoying lag in fl_topside either.
If it needs gnome3 to replicate or "compositing window managers" then it seems I'm safe for now, cause i'm not aware of any such things existing in my computer.
-
To quote freedesktop.org: "The Weston compositor is a minimal and fast compositor and is suitable for many embedded and mobile use cases." (https://wayland.freedesktop.org/)
It seems to me that you, like most freedesktop related projects don't understand the definition of minimal.
You not understanding the benefit of software rendering also suggests you have no idea what tinycorelinux minimalism is about.
-
I didn't have noticeable lag when I moved windows in windows 95
But you had tearing. Lots of it. And repainting artifacts. Lots of them. Which is true for all versions of Windows prior to Windows Vista. Windows Vista introduced DWM (Desktop Window Manager), which is a compositing window manager, which got rid of all that mess which is tearing and repainting artifacts, but read for yourself:
https://blogs.msdn.microsoft.com/greg_schechter/2006/03/19/dwms-use-of-directx-gpus-and-hardware-acceleration/
https://msdn.microsoft.com/en-us/library/windows/desktop/ff684179(v=vs.85).aspx
and i don't have any annoying lag in fl_topside either.
But you have tearing. See above.
If it needs gnome3 to replicate
It does not need GNOME 3 (which comes with Mutter, which is a compositing window manager). And, as already mentioned, Mutter @ X is actually not that bad in this regard. There are other X compositors which are worse.
With Wayland compositors (such as Mutter @ Wayland or Weston), those issues are gone.
or "compositing window managers" then it seems I'm safe for now, cause i'm not aware of any such things existing in my computer.
You almost certainly will experience screen tearing and repainting artifacts when you're not using a compositor. In theory, it would be possible to get a tear free experience with certain DDXs, such as xf86-video-intel and xf86-video-ati/xf86-video-amdgpu, since they have a "TearFree" option, but in practice, that doesn't work so well...
By the way, here's an interesting thread about the whole topic:
https://www.reddit.com/r/linux/comments/5f4ul3/does_wayland_actually_eliminate_tearing/daifis8/
;)
-
Wayland is interesting, i've never used it, on paper exciting. Does Wayland only run Gnome, KDE or Weston. What about all the great WMs, they need xwayland added to the mix? That's my understanding, if so 'an X server running on top of wayland' sounds bloated and complicated. There are probably lots of old Tiny Core systems with software rendering only, please don't exclude these systems at the expense of something less proven, still in active development.
Great Wayland made it into *Core, default probably not for many years anyway. FWIW old hardware with the right software in present TC does not lag or tear. Running modern Gnome would cripple this hardware, it's easier to avoid the bloat than figure out a workaround.
pq5190362 If you're serious then provide numbers and a test ISO, as already suggested. To be default it needs to work across all hardware and provide the same functionality or better than presently offered. Creating a TC respin is an alternative, develop it over a few months and release something fantastic.
-
good. i only care about lag. i don't care about tearing. that's why i asked for proof of your first claim that this helps improve lags.
-
pq, your behavior towards others is insulting, and how you sprinkle smileys on top of demands is making me consider a temporary ban. That is no way to behave in this community.
So, you're arguing without knowing the numbers...
I know quite well it's lots more.
Mesa > 10mb (just drivers, llvm and libs not included)
llvm-lib 5.6mb
KMS 1.5mb
...
All components not currently needed in the base.
And how's that an issue? Intel/AMD/NVIDIA hardware, they are all supporting KMS, at least with the open source drivers.
Much of the hw we support does not have any KMS drivers. And for the hw that does, we don't want to force users to install the 1.5mb support.
Which Intel/AMD/NVIDIA hardware supports out of the box when using the open source drivers as far as I know.
Indeed it does. At the cost of >30mb space.
I doubt software rendering is required when using open source drivers on Intel/AMD/NVIDIA hardware, which is probably being used by the majority of users in the (almost) year 2017 :).
It appears you aren't familiar with our supported hw base. We support everything from 486 up, having minimal and embedded targets, while being suitable for VM's, appliances and small servers. Desktop use is not discouraged, but for a user with 2017 hardware looking for a modern experience, there are other distributions such as Ubuntu that might suit them better.
-
Start GNOME 3 @ X (with Mutter as the hardware accelerated compositing window manager incl. Vsync). Now open a window and place the mouse cursor on the window titlebar and click and hold the left mouse button and move the mouse around to move the window around. As you can see, the mouse cursor is faster than the window movement, i.e. there's some kind of input/rendering/drawing lag.
...
Start GNOME 3 @ Wayland and do the same (i.e. move a window around). You will see that the mouse cursor and window movement is in perfect sync and it feels much less laggy and rock solid.
...
The same is also true for running Wayland @ Weston.
Entirely unscientific testing, but with corepure64 if I start gnome 3 and whizz a gnome-terminal window around in circles, it does not look any different to starting weston with the drm backend and whizzing a weston-terminal window around in circles.
-
Hi hiro
good. i only care about lag. i don't care about tearing. that's why i asked for proof of your first claim that this helps improve lags.
For what it's worth, with my hardware I've found that anything terminal based benefits greatly by setting Aterm*transparent
in .Xdefaults to false.
-
It looks very much like the mutter wayland backend will not compile without systemd, in which case wayland cannot be used with the corepure64 version of the gnome desktop.
-
pq, your behavior towards others is insulting
No, it's not. This...:
i.e. support their crappy feature request
is what's insulting.
and how you sprinkle smileys on top of demands is making me consider a temporary ban.
If you think that smileys are something negative, then, well, yeah, maybe you should go ahead... But feel free to delete the entire account then instead of just banning it. But please consider banning hiro first.
Desktop use is not discouraged, but for a user with 2017 hardware looking for a modern experience, there are other distributions such as Ubuntu that might suit them better.
Then I ask myself why Juanito seems to prefer getting the full fledged GNOME 3 up and running instead of the much more minimal Weston.
-
gnome is already up and running with X, so I thought (wrongly) that adding wayland support would be easy.
As far as I know, weston is just a test vehicle - as mentioned above, I got it working, but it doesn't really do much out of the box.
-
As far as I know, weston is just a test vehicle - as mentioned above, I got it working, but it doesn't really do much out of the box.
Well, I don't see how FLWM is doing more than Weston. Anyway, there are quite a few Wayland compatible compositors / window managers / desktop environments, the Arch Linux Wiki has a list of them, see:
https://wiki.archlinux.org/index.php/wayland#Window_managers_and_desktop_shells
You can test out a few of them by running RebeccaBlackOS:
https://sourceforge.net/projects/rebeccablackos/
-
weston will be available in the corepure64 8.x repo
-
@pq5190362 please stop misquoting me in this out of context way.
-
It looks very much like the mutter wayland backend will not compile without systemd, in which case wayland cannot be used with the corepure64 version of the gnome desktop.
May I ask how you came to the conclusion that systemd is required to build Mutter with Wayland support?
-
Ah, just came across this:
https://github.com/dantrell/gentoo-project-gnome-without-systemd/blob/master/README.md
-
Also found this:
https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/
and this:
https://en.wikipedia.org/wiki/Systemd#Integration_with_other_software
Anyway, what would be so bad about systemd on Tiny Core Linux?
-
May I ask how you came to the conclusion that systemd is required to build Mutter with Wayland support?
Although the configure script does not halt with an error, config.log shows that the script has searched and failed to find libsystemd and make fails with an unknown type name error.
Neither of the above occurs without the wayland backend.
-
Ah, just came across this:
https://github.com/dantrell/gentoo-project-gnome-without-systemd/blob/master/README.md
From the link above:
This project delivers:
GNOME without systemd and with basic functionality
...
The only feature which does not work is Wayland.
-
Yes, the root cause is explained over there:
https://blogs.gnome.org/ovitters/2013/09/25/gnome-and-logindsystemd-thoughts/
https://en.wikipedia.org/wiki/Systemd#Integration_with_other_software
What would be so bad about systemd on Tiny Core Linux?
-
Hi pq5190362
What would be so bad about systemd on Tiny Core Linux?
That's been covered in this thread:
http://forum.tinycorelinux.net/index.php/topic,16961.msg101662.html#msg101662
-
Looks like it's now possible to use GNOME/Mutter on Wayland without systemd by making use of:
https://wiki.gentoo.org/wiki/Elogind
https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd
https://github.com/elogind/elogind
https://github.com/dantrell/gentoo-project-gnome-without-systemd
-
i thought you already said this.
emulating more systemd stuff means the architecture is driven by systemd regardless.
wayland is still mainly freedesktop driven and in that the implementation is totally braindamaged. i don't recommend basing anything on it.
-
Then you thought wrongly. I had not said this earlier.
Previously it said:
The only feature which does not work is Wayland.
Now it says:
The only feature which does not work is Wayland (unless you are using an elogind implementation).
:)
So, there have been a few advances in the meantime. With elogind, it's now possible to even use Wayland on GNOME without systemd.
-
elogind is a part of systemd. whether you drag all the parts of systemd in individually or infest the whole system once doesn't make a real difference IMO. it's still systemd.
so you still cannot use this without (at least parts of) systemd.
-
elogind is a part of systemd. whether you drag all the parts of systemd in individually or infest the whole system once doesn't make a real difference IMO. it's still systemd.
Maybe read properly?
1. elogind is not part of systemd, it has been extraced from systemd to run stand-alone
2. Using elogind is neither dragging all parts of systemd in individually nor is it using entirely using systemd at once, it's simply using elogind as stand-alone software
So you should go back and read all of this again:
https://wiki.gentoo.org/wiki/Elogind
https://wiki.gentoo.org/wiki/GNOME/GNOME_Without_systemd
https://github.com/elogind/elogind
https://github.com/dantrell/gentoo-project-gnome-without-systemd
But considering your track record of jumping to conclusions and being against everything new from the get-go, maybe you can spare yourself from reading it in the first place.
-
This doesn't sound like "Hey, here is some info" but like "Hey, I know better than you".
2ยข
-
What would be so bad about systemd on Tiny Core Linux?
-
GNOME Mutter 3.29.1 Now Works With Elogind, Allows For Wayland On Non-Systemd Distros
https://www.phoronix.com/scan.php?page=news_item&px=GNOME-Mutter-3.29.1
Mutter can now be built with elogind. That is the systemd-logind as its own standalone package. This in turn allows using Mutter with its native Wayland back-end on Linux distributions using init systems besides systemd.