Page 1 of 2 12 LastLast
Results 1 to 10 of 18

Thread: Qualcomm's Open Kernel Driver Leads To A Dirty Mess

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

    Default Qualcomm's Open Kernel Driver Leads To A Dirty Mess

    Phoronix: Qualcomm's Open Kernel Driver Leads To A Dirty Mess

    Well, it sounded nice when Qualcomm announced an open-source 2D/3D kernel driver for their Snapdragon platform that's used by phones like the Nexus One and Dell Streak, but it turns out that their user-space Linux driver that hooks into this kernel driver is currently a closed-source blob. This has led to the eternal debate about open-source kernel components but with only closed-source components...

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

  2. #2
    Join Date
    Jul 2008
    Posts
    14

    Default

    I just can't understand. Why is it worth to pay a few people to make a closed source driver than releasing the source and get a much better driver for almost free...?

  3. #3
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote Originally Posted by balihb View Post
    I just can't understand. Why is it worth to pay a few people to make a closed source driver than releasing the source and get a much better driver for almost free...?
    Because the rule of thumb is that your chances of getting a good GPU driver are proportional to your willingness to hire skilled people to write one.

  4. #4
    Join Date
    Nov 2008
    Location
    Germany
    Posts
    5,411

    Default

    open-source can be understand wrong in many ways.

    as intel in the past opensource-code of the GPU-driver but no spec
    means if they do not support the driver by an internal NDA feedet team the driver goes useless in the future.
    best exampel is my mom's 2ghz P4 igp G845 ubuntu 10.04 and 10.10 fails complete on this hardware because of the closed-NDA-intel-Development.
    without hardware specs you don't have a hardware....
    yes intel release specs after amd does but intel do not break the ICE amd does it!

    same problem by via/s3 dev a kernel drm for an cloused source driver FAIL and to late for the spec just to 'late'

    amd do have some misunderstandings to in the past to.
    they wana save HDCP copy-protection in the UVD unit but they need 2007-2010-6 3,5 Years of time to check out that the reverence card of the R600 opensource driver the hd2900 do not have a UVD unit at all!!!!!!(you can read this amd-fail at bridgmans forum log and i save him from that mistake (i save the opensource driver))

    and now o wow!... they wana dev a shader based opensource acceleration because they unterstand now there is no UVD unit to save in the R600 reverence hd2900 hardware LOL! 3,5 Years to 'late'

    there are so many ways of misunderstanding the beauty of open-source-drivers

  5. #5
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    As it should be. Props to David!

  6. #6
    Join Date
    Jan 2008
    Location
    Have a good day.
    Posts
    678

    Default

    Wait, can I actually overwrite my passwd file to gain 5 FPS in games??? Why NOBODY told me?

  7. #7
    Join Date
    Aug 2009
    Posts
    2,264

    Default

    Quote Originally Posted by yotambien View Post
    Wait, can I actually overwrite my passwd file to gain 5 FPS in games??? Why NOBODY told me?
    I was actually wondering how a command executed by the GPU could possibly modify a file on a FS, but that might just be me...

  8. #8
    Join Date
    Aug 2007
    Posts
    6,675

    Default

    @Qaridarium

    Maybe you always try too experimental driver combinations. Use Kanotix

  9. #9
    Join Date
    Jan 2008
    Posts
    772

    Default

    Quote Originally Posted by V!NCENT View Post
    I was actually wondering how a command executed by the GPU could possibly modify a file on a FS, but that might just be me...
    I'm pretty sure Dave was being facetious in that particular spot (using that as an absurd example of sacrificing a core goal like security/reliability). As he alludes to later in the message, though, an insecure GPU driver could potentially be used to read/write arbitrary RAM with DMA operations, which means that an attacker could modify/replace privileged code. The DRM driver might inspect these operations and reject ones that go out of the appropriate bounds, but again it might be hard to know whether that's happening (or happening correctly) if they're trying to keep the GPU programming details a secret.

  10. #10
    Join Date
    Jan 2008
    Location
    Have a good day.
    Posts
    678

    Default

    Quote Originally Posted by Ex-Cyber View Post
    I'm pretty sure Dave was being facetious in that particular spot (using that as an absurd example of sacrificing a core goal like security/reliability).
    Uuuh, you never know. Sometimes there are hidden bugs/features where least expected.

Posting Permissions

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