Results 1 to 7 of 7

Thread: No, ARM Didn't Open-Source Their Full Mali Linux Driver

  1. #1
    Join Date
    Jan 2007
    Posts
    15,110

    Default No, ARM Didn't Open-Source Their Full Mali Linux Driver

    Phoronix: No, ARM Didn't Open-Source Their Full Mali Linux Driver

    A few Phoronix readers have written in with excitement thinking in recent weeks - including this morning - that ARM open-sourced their Linux/Android graphics driver... But in reality, nothing has changed...

    http://www.phoronix.com/vr.php?view=MTY3OTM

  2. #2
    Join Date
    Nov 2010
    Location
    California
    Posts
    331

    Default Linus says...

    Quote Originally Posted by phoronix View Post
    Phoronix: No, ARM Didn't Open-Source Their Full Mali Linux Driver

    A few Phoronix readers have written in with excitement thinking in recent weeks - including this morning - that ARM open-sourced their Linux/Android graphics driver... But in reality, nothing has changed...

    http://www.phoronix.com/vr.php?view=MTY3OTM

  3. #3

    Default Be Carful ARM

    Those Braswell chips are a coming.

  4. #4
    Join Date
    Mar 2009
    Location
    in front of my box :p
    Posts
    811

    Default

    Oh well. Intel and AMD now reach low power regions but offer good perfomance and come with way better GPU drivers. I never understood how all those ARM based solutions in the past could have such lousy Linux support when Linux seemed the main target platform. I admit it was mainly the GPU part that was horrible. Probably they thoght somebody would build a device with a static software that will stay the same the next 20 years. But software is dynamic, even on the same hardware base. I want to use new kernels, bug-fixed new X.orgs and whatsnot. I don't want to be forced to be stuck with some ancient Kernel/X/... just to have a half-assed binary blob executing at all (not to say "working").
    Well, I am really looking forward to AMD's little Mullins platform... might feature everything we know from the PC in small form factor, low power and all that for an affordable price. And I intend to spend money sooner or later.

  5. #5
    Join Date
    Sep 2008
    Location
    Vilnius, Lithuania
    Posts
    2,601

    Default

    In other words, old Broadcom chips stay the most open, then.

  6. #6
    Join Date
    Nov 2012
    Location
    France
    Posts
    593

    Default

    Quote Originally Posted by Slartifartblast View Post
    Those Braswell chips are a coming.
    Their prices are coming.

  7. #7
    Join Date
    Jan 2012
    Posts
    113

    Default

    Quote Originally Posted by Adarion View Post
    I never understood how all those ARM based solutions in the past could have such lousy Linux support when Linux seemed the main target platform.
    Android is their main target platform. This has a lot of implications. For example, Android is not using KMS for their display drivers. Which causes the "traditional fbdev" vs. "KMS" fragmentation. And a bit of a pain for the people, who want to adapt the Android vendor kernel to mainline Linux It's kinda funny that KMS (kernel mode setting) is a misleading name, because the fbdev drivers are also doing mode setting in the kernel. Just the API is different.

    I admit it was mainly the GPU part that was horrible. Probably they thoght somebody would build a device with a static software that will stay the same the next 20 years. But software is dynamic, even on the same hardware base. I want to use new kernels, bug-fixed new X.orgs and whatsnot. I don't want to be forced to be stuck with some ancient Kernel/X/...
    AFAIK only PowerVR SGX is evil enough to ship Xorg DDX blobs, forcing you to use ancient X and also horrific 2D performance.

    In the case of Mali400, the Xorg DDX is half-assed, but it is open source: http://malideveloper.arm.com/develop...splay-drivers/
    And it can be easily replaced with another DDX, for example https://github.com/ssvb/xf86-video-fbturbo (formerly called xf86-video-sunxifb).

    just to have a half-assed binary blob executing at all (not to say "working").
    The binary blob is only providing OpenGL ES. Which is not very critical, because OpenGL ES is rather unpopular in Linux nowadays and very few applications can make any use of it. Maybe Wayland can change this and and promote wider use of real OpenGL ES. Also Qt5 looks promising if the applications start using it eventually.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •