Announcement

Collapse
No announcement yet.

Wayland/Weston 0.95 Land In Ubuntu 12.10

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    Originally posted by AJSB View Post
    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.

    Originally posted by AJSB View Post
    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


    • #17
      Originally posted by Teho View Post
      ...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


      • #18
        Originally posted by hiryu View Post
        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


        • #19
          Originally posted by AJSB View Post
          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.


          Originally posted by AJSB View Post
          ....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).

          Originally posted by AJSB View Post
          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.

          Comment


          • #20
            Originally posted by Teho View Post
            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.
            Last edited by AJSB; 08-26-2012, 06:05 PM.

            Comment


            • #21
              Originally posted by AJSB View Post
              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.

              Originally posted by AJSB View Post
              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.

              Comment


              • #22
                Originally posted by Ancurio View Post
                Please don't feed the trolls...
                *sigh* you're right...

                Comment


                • #23
                  Originally posted by elanthis View Post
                  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.

                  Originally posted by elanthis View Post
                  "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.

                  Originally posted by elanthis View Post
                  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.

                  Originally posted by elanthis View Post
                  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.
                  Last edited by hiryu; 08-26-2012, 08:01 PM. Reason: Incomplete explanation.

                  Comment


                  • #24
                    Posters suggesting that pro/competitive-gamers notice 10ms differences in latency are correct. When you're playing, you aren't really reacting, you're pushing buttons in a timed sequence. It becomes, "How quickly can I push F1 followed by F2, and still have them both register correctly in the sequence which you entered them". Press F2 too soon after F1, either the sequence isn't registered (comp thinks you pushed both at the exact same time), or one of the hits doesn't register at all.

                    I hit the top 20 players on BC in Eve online as an interdictor pilot that leveraged a Low-latency setup that was little more than, F1 --> F2, F3, F2, click, F3, F2, click, F3, F2, click, F3, F4, click. The whole process took less than a second, and assured that whatever came through the stargate wasn't going anywhere. Watch it on video and it looks like I'm just spamming the keyboard and mouse for a moment. It couldn't be Fraps'd because Fraps would increase the latency too much to pull off the maneuver.

                    F

                    Still top 30 after 6 months away from the game.
                    Last edited by russofris; 08-26-2012, 09:08 PM.

                    Comment


                    • #25
                      Originally posted by Teho View Post
                      I don't think so. They should just fix the bugs their users have with PulseAudio.

                      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.
                      Well i would agree with the bug fixes but the truth is that the PA dev seem unable to fix these bugs and actually have the nerve to dismiss them discarding the responsibility to the apps....witch is funny taking in account their goals for PA with a perfect integration with ALSA,etc.
                      If their goals were a perfect integration , THEY FAILED to deliver.
                      But maybe the real reason is another...i believe that there is something fundamentally flawed in PA that not could simply be solved with "bug fixes".....maybe KLANG would the right answer.

                      ...and you didn't listen to me....so i will repeat:

                      All apps that use audio in Slackware simply work and work properly w/o PA.

                      Many apps (in special games, mind you, not only very demanding games but even simple JAVA FICS clients like JIN) that use audio via PA in *UBUNTU* or it's derivatives like *LINUX MINT* DON'T WORK AT ALL as for AUDIO goes.


                      So you are seeing things upside down...ALSA, except for the users that need multichannel (...and NO serious player EVER uses multichannel in a game even if it supports it) works just fine w/o latency problems, mysterious sound mutes/crashes or w/o make game CTD.
                      PA, OTOH, makes all those nasty things with a bunch of games.



                      ...and talking about games....did you noticed how quiet VALVE been lately ?

                      They promised updates and nothing yet.......

                      Did Michael saw L4D2 at Valve running with audio ON or OFF ?!?

                      I wonder if Valve was comparing only *video* performance w/o audio enabled in both Windows and LINUX and now hit a sudden audio "issue" .


                      I bet that in the end we will see a SteamOS UBUNTU-based new distro w/o PA using only ALSA or maybe ALSA+KLANG....and Nouveau ditched with a proper NVIDIA blob preinstalled.
                      Last edited by AJSB; 08-26-2012, 09:35 PM.

                      Comment


                      • #26
                        Originally posted by AJSB View Post
                        Bur even talking about PA, UBUNTU and others should give a TRUE AND SIMPLE WAY TO DISABLE IT if we want
                        It is called pasuspend, but its seldom used as things work just fine by default. Also, you are full of lies: https://help.ubuntu.com/community/In...ion/MinimalCD/

                        Short story? Don't like it, don't use it. Use your fav distro and let others use theirs. To each their own.

                        My experience with PA is that it works just fine (Using Xubuntu 12.04). I run wine games (Ie. Skyrim, Civ4, etc) with sounds playing along with media players and web browsing (youtube et all) and it all works as expected, simultaneously even. I have reproduced the same experience in various different machines; you might have a particular problem with your setup.

                        Valve doesn't need to do any disabling because the stuff works fine. What they might do is customize the interface for their own needs if they go with a linux console or games distro and need a much simpler interface; Ubuntu TV style.
                        Last edited by Artemis3; 08-26-2012, 09:50 PM.

                        Comment


                        • #27
                          Originally posted by Artemis3 View Post
                          It is called pasuspend, but its seldom used as things work just fine by default. Also, you are full of lies: https://help.ubuntu.com/community/In...ion/MinimalCD/

                          Short story? Don't like it, don't use it. Use your fav distro and let others use theirs. To each their own.

                          My experience with PA is that it works just fine (Using Xubuntu 12.04). I run wine games (Ie. Skyrim, Civ4, etc) with sounds playing along with media players and web browsing (youtube et all) and it all works as expected, simultaneously even. I have reproduced the same experience in various different machines; you might have a particular problem with your setup.

                          Valve doesn't need to do any disabling because the stuff works fine. What they might do is customize the interface for their own needs if they go with a linux console or games distro and need a much simpler interface; Ubuntu TV style.
                          I know very well pasuspend, DOESN'T solve the problems AT ALL.
                          Full of lies on what ?!? WTF as the minimal CD to do with PA and UBUNTU ?!? Does yjr minimal CD not include PA ?!? Let's imagine that it doesn't....SFW ?!? As soon as you start to pull the audio-related apps from the UBUNTU repositories, it will install PA.


                          Yeah, in that you are correct, i don't like it , i don't use it.


                          BS !!! You play the *WINDOWS* versions of them via WINE..
                          Play a NATIVE game like ETQW in a PC with REALTEK AUDIO and press one of the VOIP buttons of the game....CTD.
                          Install a JAVA game like JIN FICS Chess client, enable audio and let's see if you get any audio of it.
                          etc, etc.

                          Notice that i had two MB with build-in audio from different brands and same s**t with PA happened .

                          Comment


                          • #28
                            Originally posted by elanthis View Post
                            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)
                            Can you elaborate a bit on this? From what I know vsync should work the following way: once frame x is sent to the monitor rendering starts for frame x + 1 with whatever information is available at that time and not render anything else until the next vsync event. Now, at 60 fps the interval between frames is ~16ms. If rendering the next frame took just 4ms and somewhere between ms 4 and 12 new info comes from another player should a properly coded engine render a new frame that takes into account this new info?

                            Comment


                            • #29
                              Originally posted by AJSB View Post
                              Well i would agree with the bug fixes but the truth is that the PA dev seem unable to fix these bugs and actually have the nerve to dismiss them discarding the responsibility to the apps....witch is funny taking in account their goals for PA with a perfect integration with ALSA,etc.
                              If their goals were a perfect integration , THEY FAILED to deliver.
                              But maybe the real reason is another...i believe that there is something fundamentally flawed in PA that not could simply be solved with "bug fixes".....maybe KLANG would the right answer.

                              ...and you didn't listen to me....so i will repeat:

                              All apps that use audio in Slackware simply work and work properly w/o PA.

                              Many apps (in special games, mind you, not only very demanding games but even simple JAVA FICS clients like JIN) that use audio via PA in *UBUNTU* or it's derivatives like *LINUX MINT* DON'T WORK AT ALL as for AUDIO goes.


                              So you are seeing things upside down...ALSA, except for the users that need multichannel (...and NO serious player EVER uses multichannel in a game even if it supports it) works just fine w/o latency problems, mysterious sound mutes/crashes or w/o make game CTD.
                              PA, OTOH, makes all those nasty things with a bunch of games.



                              ...and talking about games....did you noticed how quiet VALVE been lately ?

                              They promised updates and nothing yet.......

                              Did Michael saw L4D2 at Valve running with audio ON or OFF ?!?

                              I wonder if Valve was comparing only *video* performance w/o audio enabled in both Windows and LINUX and now hit a sudden audio "issue" .


                              I bet that in the end we will see a SteamOS UBUNTU-based new distro w/o PA using only ALSA or maybe ALSA+KLANG....and Nouveau ditched with a proper NVIDIA blob preinstalled.

                              You're implying that Steam, or for that matter, any serious game devs actually talk to PA. They don't. They use abstractions like OpenAL or SDL_mixer, which work flawlessly with PA.

                              You're talking about "bugs in PA". Can you point out some, as well as the source code in PA that is responsible for them? That would certainly interest me.
                              Maybe I'm just biased because I've been running PA since Fedora14 without any problems whatsoever.

                              Oh, and you might want to consider that devs of normal apps might phase out direct ALSA support entirely because PA has become the de facto standard.
                              And your argument would become the same as
                              "Why do they shove GTK2 down our throats? Everything worked perfectly with GTK1, but now everything breaks when I remove GTK2!".
                              Distros can't accommodate for every nitpick users might have. "I don't wanna use Devkit! Why won't they let me use HAL?" "I don't wanna use DBus! Why won't they let me use CORBA?"
                              This is free software. If something doesn't work for you, move on.

                              Comment


                              • #30
                                Originally posted by Ancurio View Post
                                Distros can't accommodate for every nitpick users might have. "I don't wanna use Devkit! Why won't they let me use HAL?" "I don't wanna use DBus! Why won't they let me use CORBA?"
                                This is free software. If something doesn't work for you, move on.
                                That's pretty much what Gentoo is trying to do, and it's doing a pretty decent job. I have 3 machines running Gentoo, 2 of them running over plain alsa and one with PA, all 3 work flawlessly. And I could even switch one to OSS if I wanted, though I think there would be some apps that no longer have OSS output even as compile time option...

                                Comment

                                Working...
                                X