Wayland/Weston 0.95 Land In Ubuntu 12.10

[hiryu]

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).

Gotcha.

"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).

In the situation I referred to, all of the better players noticed the issue and it was clear there was an issue when they played. The next day when they had brought in the new monitors, the players no longer had an issue and it was clear they were playing better. I believe the issue was with SF3 3rd strike. The players would throw regular attacks out there and immediately after the attack, they'd do the movement of a super combo and should the attack connect and not be blocked, they'd hit the appropriate button and go directly into the super combo. With the slower monitors, the players weren't able to pull this off anymore. With the new monitors the next day, this was no longer an issue.

I've no doubt that in the gamer's quest for lower latency, you see a lot of the same mindset that you see with audiophiles, but occasionally it is a legitimate issue. We had one better player from out of town come in and complain about lag issues on a cabinet with CRT. Either it was imagined (probably), or possibly his problem is that he was too used to the lag of a crappy LCD.

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.

I agree.

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.

This is probably the best solution. I know at least some console titles implement this.

[hiryu]

Please don't feed the trolls...

*sigh* you're right...

[Teho]

Bur even talking about PA, UBUNTU and others should give a TRUE AND SIMPLE WAY TO DISABLE IT

I don't think so. They should just fix the bugs their users have with PulseAudio.

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's not how it works. Ubuntu and Debian compile packages with PulseAudio support enabled and Slackware doesn't. PulseAudio is compatible with ALSA so those applications will still work on Slackware altough they can't take use of any PA features and might not work properly. Application usually depend on libpulse that does exactly what you are after: if PulseAudio is not present then it uses ALSA.

[AJSB]

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.

[Teho]

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).

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.

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.

[elanthis]

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.

[AJSB]

...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.

[Teho]

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.

[Ancurio]

I don't understand all the anti-Wayland hate out there.

Please don't feed the trolls...

[freedam]

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

Here is the package:

http://www.slacky.eu/asche/pkgs/index.php?sear=pulseaudio

SO, in Slackware, WE have a choice....i bet that in a maximum of 3 (maybe 2) years you won't have a choice in UBUNTU.

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


...and BTW....is LP one of the Wayland devs ?

Yes, it is one of Lennart's evil projects, he is only hiding behind another name because he's afraid of you.