If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

Progress is fine. Breaking my stuff in the name of progress is not! This is why I hate them forcing this Wayland bulls***. We will have to use it and then find out half the applications either don't work or are seriously crippled. And then the wayland devs won't accept that they are idiots, they will blame the applications for not being compatible with them and not following their "rules".

Can you name one application that you know for a fact will not work when wayland becomes the unalterable default in ubuntu?

Comment

I don't understand all the anti-Wayland hate out there. There's some issues that I see (that I'll get to below), but overall it's progress we need. At first, I wasn't sold on wayland, but lets face it, bolting compositing on top of X hasn't worked so well. I boot into windows 7 (less than once a week), and it's clear how much more smooth the compositing is there. Look at the diagrams of how compositing works in X and you'll start to see why things don't run as fast and smooth as they should. I have a core i7 980x, a GTX580, 18GB of memory and an SSD (well, /home is on a 2TB RAID1 array on a 3ware 9750 SATA III controller), and I can't hit anywhere close to a stable 60 fps on my desktop, it's ridiculous. At least my desktop in Linux is snapper, even if it's choppy.

The Wayland architecture should give us a significant and much needed speed boost. It matches up with how modern hardware works, and removes a lot of the unnecessary middlemen inside of the X architecture. I am a bit concerned that some dists may end up trying to push wayland before it's truly ready for prime-time (and/or perhaps before xwayland is also ready). Should this happen, those distributions will end up bleeding users pretty badly and therefore the problem will solve itself.

Here's my problems with wayland:
1. Remoting really isn't being built-in, but will potentially tacked on later. Remoting is awesome, and I think we're throwing out the baby with the bathwater here. Presently, the idea to get remoting in Wayland is to write a compositor that takes the buffers for the windows, and sends them over the network to some remote machine. Not knowing Wayland's architecture too well, will this allow for sharing of individual windows (hacks where the entire desktop is still running on the original machine doesn't count)? The other problem that the the remote machine now must handle drawing the windows instead of the machine with the display. In X, the machine with the display (the server) does the drawing which puts less load on the remote client machine (imagine when a remote machine has to draw for several clients, you can see how this could become a problem). Wayland windows are all drawn via GPU too, correct? This means the remote machine sending the windows over the network would also have to have a GPU powerful enough to handle all of the drawing now.

But maybe this point isn't such a big deal. Correct me if I'm wrong (I'm a big fan of constructive criticism), but my understanding is that the way things are currently done is X is that the toolkits handle all the drawing themselves, not using any of the obsolete X.org drawing commands, then just send/copy all the pixels to the X server (whether the X server is on the local machine or not). This would mean the drawing is already being done on the client machine in X anyway so the Wayland approach to remoting wouldn't really change much here.

2. Are the Wayland devs still locking things to the refresh rate of the monitor? For most people, 60 fps is fine, but there may be cases where this is not sufficient. I know this has been debated on this forum in the past, but there are times when the latency from 60 fps may be too high (especially when you add this to the latency of the monitor). How do I know? I own an arcade where we regularly throw tournaments. We have some professional players come in (and even occasionally some semi-big ones, but I won't drop any names), and latency is a big concern of their's. My business partner and I were aware of the issue before we even opened the business so we've never had any issues, but this has been a problem in some other big tournaments (we're small fries) where they had to replace the monitors during the event (I believe this might've even happened at Evo once years ago). In fighting games, timing is everything. In FPS games, accuracy is everything. Latency at this level may not be an issue for us mere mortals, but it comes to the tournament players, this matters.

Then there's the issue of when the framerate can't keep up with the refresh rate... What if the framerate dips to 59? Well, you're not going to see 59 fps, it's going to drop to something like 30 or 45 fps to sync up with the monitor which can jarring and ugly (but is at least still tear-free). For the desktop in general, this tradeoff is clearly worth it. But for a game, having the ability to enable or disable vsync is pretty important. Hopefully applications will be able to support enabling and disabling vsync on an individualistic basis at least eventually.

Comment

As for xWayland , we all know that will be only an interim solution, it will be dropped real fast by Wayland devs...

XWayland is implemented in X.org and Weston. Even if it was dropped by Weston developers (it won't) it would really matter as there will probably be at least four major Wayland compositors for desktop Linux: KWin, Mutter, Compiz and Weston and all will have to implement it themselves. Due to fact that there's a lot of scietific and other propietary software that depend on X I don't see how Red Hat or SuSE or even Ubuntu could drop it. If there's enough intrest it could be maintained forever.

What are you mumbling about ? *IF* i wanted PulseAudio, as an example, i also can have it in Slackware.

...and if you don't want to use PulseAudio on Ubuntu or on any other distribution for that matter you don't have to either. It's just that Ubuntu packages Gnome and other software that have hard dependecy on it. You actually have a lot more choise on Ubuntu because it provides more software than Slackware.

Comment

...and if you don't want to use PulseAudio on Ubuntu or on any other distribution for that matter you don't have to either. It's just that Ubuntu packages Gnome and other software that have hard dependecy on it. You actually have a lot more choise on Ubuntu because it provides more software than Slackware.

Aaaaahhhh, *there* is the problem ....i removed Pulse Audio from UBUNTU and almost everything was working OK....then i tested WET and JIN and there was no way to get audio playing from them....i found more with same problem...is much better to not have it in a base installation and add it if you really want than the other way around.

....and it's not only UBUNTU that hardwires apps to PA....other distros do the same....and this is a big problem....it shouldn't be hardwired AT ALL....

As for UBUNTU have or not more software than Slackware, i'm not that sure of that....at least i never had a problem to get what i wanted/needed for Slackware.

Comment

Presently, the idea to get remoting in Wayland is to write a compositor that takes the buffers for the windows, and sends them over the network to some remote machine. Not knowing Wayland's architecture too well, will this allow for sharing of individual windows (hacks where the entire desktop is still running on the original machine doesn't count)?

Yes.

The other problem that the the remote machine now must handle drawing the windows instead of the machine with the display. In X, the machine with the display (the server) does the drawing which puts less load on the remote client machine (imagine when a remote machine has to draw for several clients, you can see how this could become a problem). Wayland windows are all drawn via GPU too, correct? This means the remote machine sending the windows over the network would also have to have a GPU powerful enough to handle all of the drawing now.

As you pointed out, all your modern X apps are already doing all the rendering locally. Fonts are rendered client-side, toolkits use APIs like RENDER (not easy to accelerate over a network protocol), etc. Your client machine will need a "powerful enough" GPU, but literally every major CPU being sold now has a GPU builtin, and ones that lack an integrated GPU will disappear over time. This is not something worth worrying about.

Are the Wayland devs still locking things to the refresh rate of the monitor? For most people, 60 fps is fine, but there may be cases where this is not sufficient. I know this has been debated on this forum in the past, but there are times when the latency from 60 fps may be too high (especially when you add this to the latency of the monitor). How do I know? I own an arcade where we regularly throw tournaments. We have some professional players come in (and even occasionally some semi-big ones, but I won't drop any names), and latency is a big concern of their's.

First off, Wayland does no such thing, as Wayland is just a protocol. Weston very well might (don't know), but it's FOSS and you can change it if you want, or just use a different Wayland server implementation (I believe at least one other is already in development by the Qt folks, but I'm not sure).

"Professional gamers" (ugh) usually imagine the latency problem; they're interested in getting any possible edge, real or not, and are all too ready to blame anything and anyone except themselves when they don't play perfectly ("I don't suck, this computer just had vsync turned on, this is bullcrap!"). You get a lot of that in any competitive sport; people who believe in lucky socks, crap like that. There's feedback bias going into it. The monitor is physically incapable of displaying faster than its refresh rate, with or without vsync. That's not to say that it wouldn't better to have higher refresh rates than the relatively low 60hz that has become standard (120hz being the golden number, as it is slightly higher than what a human can perceive and has numerical properties that make it ideal for compatibility with legacy tech), but unless the monitor supports 120hz there is zero reason to actually render at 120hz. Note also that many games are just coded improperly and suffer additional lag in the whole system with vsync on; this is not the fault of vsync or the display system in general, but rather the game engines blocking everything until a vsync event instead of merely delaying rendering (triple buffering is the easy way to fix this for games that work that way, if your driver allows you to force it on).

Then there's the issue of when the framerate can't keep up with the refresh rate... What if the framerate dips to 59? Well, you're not going to see 59 fps, it's going to drop to something like 30 or 45 fps to sync up with the monitor which can jarring and ugly (but is at least still tear-free).

And this is why we try to get such high unlocked FPS in an engine and game despite the lack of a need to actually render that fast. If your game can only just barely handle 60 FPS on target hardware, then yes you have the problem where you drop to 30 fps. If you can render 200 frames then even if you hit a major problem and start running at 50% speed you're still well over the minimum 60 FPS. For general gaming, it's better to just lock the game to 30 fps for consistency if it can't handle 60, and for competitive play it's better to turn off all the graphical bells and whistles that you don't care about so the game always runs at 60 fps no problems.

That said, adaptive vsync is a thing (sync to 60 fps if it can handle it, and disable vsync if it can't), and it would be very easy to make a Wayland do that if it turns out to be a problem. I imagine that full-screen apps could be allowed to directly set the scanout buffer as well. As is, there is only a single extra context switch required when flipping buffers, but if Wayland has a command (or possibly it can be all automated by the server with no protocol changes at all!) to map a fullscreen window to that display's scanout buffer, the app/game would be in full control of when buffers are swapped.

Comment

is much better to not have it in a base installation and add it if you really want than the other way around.

Ubuntu is distribution for non-technical people. It's important that stuff like bluetooth and multi-channel audio work properly out of the box. It's the minority that has any problems with PulseAudio so not taking advantage of these features would be plain stupid.

....and it's not only UBUNTU that hardwires apps to PA....other distros do the same....and this is a big problem....it shouldn't be hardwired AT ALL....

Ubuntu doesn't "hardwire" anything. It's the application developers who choose to do so. PulseAudio is the de facto audio server on Linux so it's no wonder why application developers might not want to waste their time supporting other audio systems for no added gain (libpulse works fine with ALSA even without PA server).

Comment

Ubuntu is distribution for non-technical people. It's important that stuff like bluetooth and multi-channel audio work properly out of the box. It's the minority that has any problems with PulseAudio so not taking advantage of these features would be plain stupid.

Ubuntu doesn't "hardwire" anything. It's the application developers who choose to do so. PulseAudio is the de facto audio server on Linux so it's no wonder why application developers might not want to waste their time supporting other audio systems for no added gain (libpulse works fine with ALSA even without PA server).

Debian has more packages than anyother distribution aside from its derivatives like Ubuntu and Mint that have even more. Slackware for one doesn't even package Gnome.

I agree that easy of use is important and no matter i have no use for bluetooth and multichannel i understand that those things might be important to some (in special Bluetooth....multichannel, not really, even when using Windows i don't use multichannel) , notice that i actually because don't use i have no clue of how hard or easy is to make bluetooth work in slackware, however , that was not the main subject of this thread but Wayland, Wayland as nothing to do directly with audio or bluetooth.
Bur even talking about PA, UBUNTU and others should give a TRUE AND SIMPLE WAY TO DISABLE IT if we want (that actually is funny taking in account what you say about UBUNTU is for the non-techie and reading all the posts in UBUNTU forums about how in the hell to disable PA and then audio not working in some apps or even worse, how to get rid of Nouveau and how to install a freaking PROPER VIDEO DRIVER with performance with same level of the one for Windows instead of that thing called Nouveau.

You say that is not UBUNTU fault that apps devs hardwire for PA....excuse me ?!? aren't those apps FOSS ?!? aren't many of those same apps also shipped with or for Slackware w/o PA ?!? So, what's so hard to UBUNTU make a kind of "if PA present use PA else use ALSA" in the code ?!?
That would make everyone happy.....but NOOOO that have to shove it down and make damn sure that it's darn difficult to remove it w/o screwing things up...

As for GNOME, taking in account that i can use GTK+ apps in Slackware, i don't really care or miss it.