Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Graphics Android Cellphones GUI Handhelds Operating Systems Software Hardware

Jolla Ports Wayland To Android GPU Drivers 90

Posted by timothy from the cross-platform-the-hard-way dept.
An anonymous reader writes "A Jolla Sailfish OS engineer has ported Wayland to run on Android GPU drivers. The implementation uses libhybis with the Android driver so that the rest of the operating system can be a conventional glibc-based Linux operating system, such as Mer / Sailfish OS. The code is to be LGPL licensed. The reported reasoning for making Wayland support Android GPU drivers was difficulty in ODM vendors not wishing to offer driver support for platforms aside from Android."
This discussion has been archived. No new comments can be posted.

Jolla Ports Wayland To Android GPU Drivers More

Jolla Ports Wayland To Android GPU Drivers

Comments Filter:

  • The reported reasoning for making Wayland support Android GPU drivers was difficulty in ODM vendors not wishing to offer driver support for platforms aside from Android."

    Why support yesterday's phone when you can just tell your users to buy tomorrow's? This kind of progressive thinking hurts profits. Profits are people. Therefore, you should be arrested. :/

    • Re: (Score:2)

      by gmuslera ( 3436 )
      Its coming from the company that is making alternative OS for cellphones, the kind that could use existing, already in market cellphones, to expand their userbase giving ways for people to install it on them (if Sailfish runs in Wayland, anyway), without having to wait for other companies to bundle sailfish with their phones or to them to be available in all markets (the announced ones so far were targeted for China or India, i think)
  • I read through the title, and the entire summary, and I still haven't got a clue what the story is all about. Jolla? Wayland? ODM Vendors? Yes, I could google, but come on! These are not common terms. Throw us a bone.

    • Re: (Score:3)

      by Yebyen ( 59663 )

      You could read the article.

      I'm not gonna. Just sayin.

      • I read the article. It didn't help much. Neither did the link to Jolla (mind you, I didn't sit through the two hours of intro video).

      • The guy has a point. Unless I already know everything about what's written here (and I probably already read the news elsewhere) I wouldn't be triggered to read the full article. It just doesn't appeal to me at all since none of the words used trigger my curiousness. By putting in just a bit more information in the summary, or even just the title, the editor/submitter would have gotten many more people interested. This is bad editing slashdots' part.

        How about "Intermediate driver for X ported to Android ha

        • Re: (Score:2)

          by Yebyen ( 59663 )

          I actually did go ahead and read the article, and I got the idea, so maybe I'm slashdot's (editors') target audience more than you.

          I think your proposed headline states too much. What's not clear to me from reading is, does the driver running in an Android system get usurped to make a Wayland display happen, or does the Wayland display take over as part of init such that Android is no longer the running system (other than the driver needed to bootstrap Wayland on this crappy hardware)

          I don't think that "on

    • Re:I've been whooshed! (Score:5, Funny)

      by caseih ( 160668 ) on Thursday April 11, 2013 @06:31PM (#43428315)

      Been away from Slashdot for a while? Wayland has Benn in the Linux news a fair bit recently. And Jolla has been mentioned quite a few times.

      But if you really don't want to read the article then I can fill you in. Wayland is the planet where the emperor hid his cloning cylinders and other artifacts he accumulated during his reign.

    • Re: (Score:2)

      by jbolden ( 176878 )

      I did this in a post above yours.

      http://tech.slashdot.org/comments.pl?sid=3639581&cid=43427825 [slashdot.org]

    • In brief:
      Jolla = A company formed by ex-Nokia employees to carry on their Linux development after the switch to Windows Phone.
      Sailfish OS = Their Linux distro for phones and tablets derived from Nokia's Meego, via a community project called Mer.
      Wayland = A potential replacement for the venerable X11.
      Android = Linux-based mobile OS which is very popular.
      ODM = Original Design Manufacturer. A company which designs and makes a product based off of another company's reference material and branding- so Samsung is

  • It's even simpler than that (Score:5, Insightful)

    by Wesley Felter ( 138342 ) <wesley@felter.org> on Thursday April 11, 2013 @05:34PM (#43427875) Homepage

    The reported reasoning for making Wayland support Android GPU drivers was difficulty in ODM vendors not wishing to offer driver support for platforms aside from Android.

    ODMs don't know how to write software, so you're better off not asking them to; the result would just be garbage anyway. All the GPU drivers are actually written by the GPU IP vendors (Qualcomm, Imagination, ARM, etc.) and they only provide Android drivers. You could try to pay them to write KMS/DRM drivers, but they'd probably quote you a price in the millions which minority platform wannabes like Jolla could not afford anyway.

  • I do hope that community distributions will pop up leveraging the work of CyanogenMod/AOSP but rather than Android on top of the custom kernel, Sailfish. I for one would love to flash my "old" Android phone (SGS+) to Sailfish (Currently on CM10). Doing that move would perhaps also break the catch 22 of users-vs-products, since (some) nerds will be happy to switch their phones from Android to "MeeGo++". The Qt on Wayland demos look sweet.... so it seems nice :) BTW: Why is Sailfish going to run on glibc? F

  • The most interesting thing is left out (Score:5, Interesting)

    by SilenceBE ( 1439827 ) on Thursday April 11, 2013 @11:28PM (#43429837)
    From the authers blog

    Earlier this year however, I discovered that a well-known company had taken the code - disappeared underground with it for several months, improved upon it, utilized the capability in their advertisements and demos and in the end posted the code utilizing their own source control system, detached from any state of that of the upstream project's. Even to the extent some posters around the web thought libhybris was done by that company itself.

    That kind of behavior ruined the initial reason I open sourced libhybris in the first place and I was shocked to the point that I contemplated to by default not open source my hobby projects any more. It's not cool for companies to do things like this, no matter your commercial reasons. It ruins it for all of us who want to strengthen the open source ecosystem. We could have really used your improvements and patches earlier on instead of struggling with some of these issues.

    http://mer-project.blogspot.fi/2013/04/wayland-utilizing-android-gpu-drivers.html [blogspot.fi]

    Canonical being Canonical

    • Re: (Score:3, Informative)

      by Anonymous Coward

      "But, I will say that their behavior has improved - they are now participating in the project, discussing, upstreaming patches that are useful. And I forgive them because they've changed their ways and are participating sanely now."

      You left out that bit of the blog post.
       

    • It doesn't sound like they actually did anything wrong. Most licenses in the wild today do not require source releases without distribution. If the developer wanted to prevent people from disappearing underground with his code, he should have put in an open repo clause. Then no one would use his software, and the problem would be solved.

  • Let's try to explain the technology (Score:5, Informative)

    by Bostik ( 92589 ) on Friday April 12, 2013 @01:50AM (#43430347)

    Phoronix article is quite low on information, and even the original post at http://mer-project.blogspot.fi/2013/04/wayland-utilizing-android-gpu-drivers.html assumes some technical knowledge of graphics stack. The basic idea is actually pretty simple. I'll try to break it down.

    1. The SoC vendors are willing to target only Android
    2. Android GPU drivers are built against Bionic libc
    3. The GPU drivers talk to hardware, and expose themselves via EGL and GLESv2
    4. EGL is basically a common API for GPU memory management, buffer (region of memory used for rendering) allocation and display updates
    5. GLESv2 stands in for the functionality we commonly associate with OpenGL

    6. GPU drivers form a combination of EGL and GLESv2 libraries, each GPU vendor providing their own

    This is where libhybris comes into play. The GPU driver libraries don't work without Bionic libc - so libhybris, while running on top of regular linux (and thus [e]glibc), keeps a private Bionic libc open for the GPU drivers' use, and redirects all the EGL/GLESv2 calls to the GPU driver libraries. These libraries run in their own Bionic universe, and tell the actual display hardware what to do.

    The new part about Wayland support is just a logical extension of the same behaviour. Wayland already depends on EGL for buffer management, so "all" it really needs is a native display handler. Now as it happens, the native Android display structure can be mapped to the Wayland-EGL display structure. It's not trivial, but it's certainly doable. Thanks to libhybris, the Wayland libraries see a correct native display type and operate on that, while the Android GPU libraries see their respective native display type and thus can drive the hardware as ever before. After all, it's still the SAME hardware regardless of what operating system we may be running. Registers are registers and memory is still memory. From the GPU drivers' point of view nothing has changed.

    So what has happened? In addition to just redirecting graphics stack calls to Android drivers, we are now also translating the display subsystem between two somewhat different systems.

    If all of the above sounds eerily familiar, you are correct. In networking this kind of design is called a proxy, or if we're talking about link layer, it would be a multi-protocol label switch. Logically there's not much difference.

    • Re: (Score:2)

      by Bert64 ( 520050 )

      So what performance impact does all this have?

      • Re: (Score:2)

        by Bostik ( 92589 )

        That is a good question.

        My answer hovers between two choices, "not a lot" and "no idea". The reason for this is that the translation code should be generally rather straightforward. There is a bigger cost for buffer allocation and destruction, and a smaller cost with frame update.

        Each time a buffer is created or destroyed, libhybris will need to do some internal bookkeeping to match the Wayland buffers with Android buffers. Some of the under-the-hood memory allocations may be more expensive than others, so

    • I looked over the libc API calls used by graphics drivers once and it wasn't anything special. Maybe less than 25 symbols.

      The point of this claim is that there is probably no need for a bionic reimplementation (bugs and all) all that needs to happen it struct layout conversion across the APIs calls. I would guess only 5 or less API calls are affected the rest follow same or similar ABI constructs for both bionic and glibc.

      The overhead, if there are no bugs/quirks to manages then next to nothing, you are c

Slashdot Top Deals

God made the integers; all else is the work of Man. -- Kronecker

Close