Announcement

Collapse
No announcement yet.

Ubuntu Touch/Tablet Is Using SurfaceFlinger

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

  • #31
    The design philosphy behind Wayland is quite similar to SurfaceFlinger. Then the best thing to to ditch Wayland, embrace and leverage the work done by Google and extend it to support a traditional desktop window manager and XSurfaceFlinger to support legacy X apps.

    Wayland has a chicken egg problem and convincing Nvidia/ATI to provide drivers for SurfaceFlinger would be much easier than for Wayland.

    Comment


    • #32
      Originally posted by newwen View Post
      The design philosphy behind Wayland is quite similar to SurfaceFlinger. Then the best thing to to ditch Wayland, embrace and leverage the work done by Google and extend it to support a traditional desktop window manager and XSurfaceFlinger to support legacy X apps.

      Wayland has a chicken egg problem and convincing Nvidia/ATI to provide drivers for SurfaceFlinger would be much easier than for Wayland.
      A great thing about wayland is that it's using existing Linux technologies (eg. KMS, DRI/DRM). SurfaceFlinger however does not. So adapting SurfaceFlinger would probably mean redoing most of the graphics stack, a huge job.

      If distributions move to wayland Nvidia and AMD will eventually support it. Supporting Linux is very important due to its' use in HPC.

      Comment


      • #33
        Originally posted by newwen View Post
        The design philosphy behind Wayland is quite similar to SurfaceFlinger. Then the best thing to to ditch Wayland, embrace and leverage the work done by Google and extend it to support a traditional desktop window manager and XSurfaceFlinger to support legacy X apps.

        Wayland has a chicken egg problem and convincing Nvidia/ATI to provide drivers for SurfaceFlinger would be much easier than for Wayland.
        Regardless of the display server used, it does not change the fact that all desktop Linux applications are written for X and must be ported over to the new server eventually.

        That will probably be the toughest thing to handle. And this is where enthusiastic end-users like me who prefer to compile their own applications from sources will be hit, since I have a nagging feeling that compiling said software is no longer as simple as just simply performing

        - ./configure
        - make
        - make install

        anymore.

        On top of that, I don't see QT5 and its wayland-capable backend being made available for even the most bleeding edge distributions, and while GTK3 has a wayland backend, the amount of software that are still tied to GTK2 is staggering, especially when big name applications like Chromium, Firefox, LibreOffice and HexChat are still happily married to GTK2 with little to no progress on GTK3 migration.

        Still, at the very least, I dare say Wayland migration with be smoother than a SurfaceFlinger migration simply because it makes use of existing Linux technologies and more importantly, work has already been done to bring some degree of Wayland support to existing toolkits.

        Comment


        • #34
          Originally posted by newwen View Post
          The design philosphy behind Wayland is quite similar to SurfaceFlinger. Then the best thing to to ditch Wayland, embrace and leverage the work done by Google and extend it to support a traditional desktop window manager and XSurfaceFlinger to support legacy X apps.

          Wayland has a chicken egg problem and convincing Nvidia/ATI to provide drivers for SurfaceFlinger would be much easier than for Wayland.
          Thats probably whats going to happen. Wayland currently powers zero distros on zero machines. SurfaceFlinger power millions of machines worldwide.

          Wayland is currently supported by zero blob drivers. Only mesa kinda supports it somehow. SurfaceFlinger is supported by most, if not all of the SoC blobs, including nVidia (tegra).

          Requiring GPU makers to support SurfaceFlinger means also supporting android. AMD is probably the only one who doesn't currently offer a driver for SF, obviously GeForce drivers aren't yet supported also, but at least some of the work is already done on nVidia's side.

          There are zero apps that currently run on wayland. Some may have been ported, but currently only use X backend, while there are thousends of apps already using SF, regardless of being fart apps.

          Finally, by using SF I think it would be even easier to support android apps. I know this is not what canonical is officially promoting, but I guess I would be dead easy for someone to port dalvik to ubuntu and enable all android apps in this platform.

          So SF is much more tested, more properly supported, more stable. The choice seems like a no-brainer to me. Maybe someone can enlighten us about the technical merits of each one...

          The missing piece of the puzzle seems to be the support legacy X apps. Maybe what canonical meant by it's own display server is a bastard son of SF and X, capable of running X apps. Time will tell, but seems to be at least a 13.10 affair...
          Last edited by Figueiredo; 02-22-2013, 09:36 AM.

          Comment


          • #35
            Originally posted by Figueiredo View Post

            So SF is much more tested, more properly supported, more stable. The choice seems like a no-brainer to me. Maybe someone can enlighten us about the technical merits of each one...
            I'm going to hazard a guess that SF won't be adopted for the following reasons:

            - the 'not invented here' syndrome
            - the need to redo the entire Linux graphics stack
            - the amount of work already done to bring Wayland and Weston up to a major recent public release
            - the amount of work put into QT and GTK3 into supporting a Wayland backend.

            That said, Im no dev, so i'll just reiterate my point: whatever display server the devs choose to bless as the de facto, just make sure it works (applications, OSS drivers, blob drivers, toolkits, compilers, etc), get EVERYBODY to adopt it and stop flirting around toying with alternatives once a decision is made.

            Comment


            • #36
              Originally posted by shmerl View Post
              Disappointing, since it means they won't put any effort in advancing Wayland on mobile.
              The problem is Linux was getting no where on mobile device due to the lack of driver support. Most support Android and are restrictive if approached for datasheets or what ever. Canonical had to bite a bullet and adopt some of Android's core so as to access the drivers and support chain. These areas will continue to be improved and updated.

              Consider the amount of different devices out there from China and mainstream that would need dedicated works just to get ported. Canonical wants success now. The problem is how to get existing software to work that maybe looking for a different windowing method. Solutions...Containers? Library distinctions?

              I'm planning to give the development thingy a go but QTCreator isn't working so well with the addins for device app building.

              What I'm surprised at is that on day 1 there has been zero patches or updates. You'd think there would be tons of activity for the release. Maybe I'll see what happens tomorrow. Maybe they were all on IRC channel helping people install.

              Comment


              • #37
                Originally posted by Sonadow View Post
                I'm going to hazard a guess that SF won't be adopted for the following reasons:

                - the 'not invented here' syndrome
                - the need to redo the entire Linux graphics stack
                - the amount of work already done to bring Wayland and Weston up to a major recent public release
                - the amount of work put into QT and GTK3 into supporting a Wayland backend.

                That said, Im no dev, so i'll just reiterate my point: whatever display server the devs choose to bless as the de facto, just make sure it works (applications, OSS drivers, blob drivers, toolkits, compilers, etc), get EVERYBODY to adopt it and stop flirting around toying with alternatives once a decision is made.
                Too easy, and too quick.

                Pains of birth are ahead of us. Our wishes will not shorten it

                In practical terms:
                X11 protocol IS BAD.
                X server IS BAD BAD BAD.

                Getting rid of its is CERTAIN.

                Now we need to make sure that we do not choose BAD over BAD. And that take time (and prototypes, and trails, and experiments, and imput from various stakeholders, and ...)
                So time it will take.

                (On a good note, every Xserver dev is quite motivated to make a switch! Working on Xorg code have something to do with it )

                Comment


                • #38
                  Something good will come of all of this

                  X11 has had how long to be lean mean graphics machine? SurfaceFlinger and QT's mobile graphics server have little amount of time out there and are on many phones and set top boxes. X11? nothing, it's developers missed to the train a long time ago to make a friendly graphics layer. I cringe everytime I have to delve into the X11 config directories and swim past prehistoric files for xcalc or something. Give us blob and OSS drivers to throw at the kernel, and load <your favorite graphics server here> that writes to it, whether on my phone, laptop, server, or SoC.

                  Comment


                  • #39
                    Originally posted by yourfriendarmando View Post
                    X11 has had how long to be lean mean graphics machine? SurfaceFlinger and QT's mobile graphics server have little amount of time out there and are on many phones and set top boxes. X11? nothing, it's developers missed to the train a long time ago to make a friendly graphics layer. I cringe everytime I have to delve into the X11 config directories and swim past prehistoric files for xcalc or something. Give us blob and OSS drivers to throw at the kernel, and load <your favorite graphics server here> that writes to it, whether on my phone, laptop, server, or SoC.
                    Are you running a prehistoric version of X11 too? Xorg has been autoconfiguring for some time so there is usually no need to edit config-files. Unless you manually have to apply some quirks to get things working, but another graphics system could have such issues too.

                    Btw, meego used X11 and the Nokia N9 is very smooth and responsive. Tizen 1.0 uses X11 (I don't know about later versions) and so does Sailfish OS.

                    Comment


                    • #40
                      Originally posted by Figueiredo View Post
                      It's funny how people in these forums start to moan and complain about things that are only in their own heads.
                      That's what these forums are for

                      Comment


                      • #41
                        Originally posted by e8hffff View Post
                        The problem is Linux was getting no where on mobile device due to the lack of driver support. Most support Android and are restrictive if approached for datasheets or what ever. Canonical had to bite a bullet and adopt some of Android's core so as to access the drivers and support chain. These areas will continue to be improved and updated.

                        Consider the amount of different devices out there from China and mainstream that would need dedicated works just to get ported. Canonical wants success now. The problem is how to get existing software to work that maybe looking for a different windowing method. Solutions...Containers? Library distinctions?
                        Comparing this to work that Mer/Jolla-Sailfish/PlasmaActive folks do, I'd say that Canonical deserted the fight to gain short term benefits. Mer/Jolla-Sailfish/PA however go along the way that desktop Linux is going - i.e. X.org -> Wayland shift. And they are working with hardware vendors. Not easy - but they are doing it instead of chickening out to grab some market. Canonical just decided to take a shortcut, but a bad one. By the way, libhybris which is apparently used by Canonical now was created by the Mer architect who also works in Jolla. For me all this is a good reason to stick with Sailfish and PA, rather than jumping to Ubuntu's train.
                        Last edited by shmerl; 02-22-2013, 12:55 PM.

                        Comment


                        • #42
                          Not so much a complaint

                          When I came to Linux, I was birthed into the notion that X was "it" and nothing more, everything graphics will use it, and you're stuck with it's huge install base and memory footprint (80MB to my phone's 8MB Resident Set Size). Then you see Mac OS X using something different, as well as Linux-based phones (surfaceflinger) and tv set tops (Roku using some qt-based server) using something lean developed just recently. Are graphics servers not that that hard to make as the X folks made it out to be? I'll avoid further complaining, but us Linux desktop users deserve something better!

                          Comment


                          • #43
                            Originally posted by yourfriendarmando View Post
                            X11 has had how long to be lean mean graphics machine? SurfaceFlinger and QT's mobile graphics server have little amount of time out there and are on many phones and set top boxes.
                            Yes you can but you don't need Canonical for that. You can use Qt for android without Canonicals contribution.

                            Do anyone know which sound daemon Canonical plan to use, is it audioflinger?
                            Last edited by Akka; 02-22-2013, 01:40 PM.

                            Comment


                            • #44
                              Originally posted by Akka View Post
                              Yes you can but you don't need Canonical for that. You can use Qt for android without Canonicals contribution.

                              Do anyone know which sound daemon Canonical plan to use, is it audioflinger?
                              PulseAudio

                              Comment


                              • #45
                                Originally posted by shmerl View Post
                                Comparing this to work that Mer/Jolla-Sailfish/PlasmaActive folks do, I'd say that Canonical deserted the fight to gain short term benefits. Mer/Jolla-Sailfish/PA however go along the way that desktop Linux is going - i.e. X.org -> Wayland shift. And they are working with hardware vendors. Not easy - but they are doing it instead of chickening out to grab some market. Canonical just decided to take a shortcut, but a bad one. By the way, libhybris which is apparently used by Canonical now was created by the Mer architect who also works in Jolla. For me all this is a good reason to stick with Sailfish and PA, rather than jumping to Ubuntu's train.
                                You make it sound like there is this honorable GNU path to follow and canonical lost this honor to follow evil guy google and its gang. if there is any thecnichal merit to wayland vs. SF, I would very much like to hear, otherwise, you do not provide any support for you claim that the shortcut canonical took is "bad".

                                The strategy seems to be working. One day after the release ubuntu touch has already been ported to the galaxy S III...
                                Last edited by Figueiredo; 02-22-2013, 02:21 PM.

                                Comment

                                Working...
                                X