[lkml]   [2009]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
    > You obviously got all this completely wrong.
    > I avoid writing closed source drivers whenever I can, I'm not whining and
    > I'm not trying to push any of them. The code VIA is trying to submit has not
    > been written by me nor anybody I know. All VIA code I and the companies I've
    > worked for has written is open-sourced and contributed to the Openchrome /
    > mesa / drm project.
    > The point I'm trying to make is the following:
    > If the common agreement of the linux community is to *NOT* allow these
    > drivers in, so be it, then be honest and go ahead and tell the driver
    > writers. Don't make them respin their development trying to fix minor flaws
    > when their driver won't get in anyway!

    I would like to raise a couple of real-life issues I have in mind:

    * First example, let's say VIA gets their Chrome9 DRM merged into the
    kernel. Now let's say I reverse engineer the hardware (or use the docs
    whenever they're available) and write a 3D component that needs
    modifications to the existing DRM interface (or maybe I realize I need
    a completely new DRM). Then who gets the upper hand? Do I have to keep
    compatibility with user space binary modules that I do not care about?

    * Second example, what is the policy if we find security holes in the
    DRM for a closed user-space afterwards? This breaks the initial
    promise of security, does that get the driver removed then? Or what if
    the promise is pending updated documentation that never arrives?

    * Third example, what if down the line we need changes in the DRM that
    require updating all DRM modules. Do we (we as in DRM developers)
    touch the DRM files for the VIA Chrome9 stuff, at the risk of breaking
    the code (since we don't test with proprietary modules)? Or do we let
    the Chrome9 files as-is, keeping the old DRM infrastructure and
    therefore add more and more DRM cruft?

    In my opinion, accepting GPL'ed DRM modules that support binary user
    space components is like opening pandora's box.


     \ /
      Last update: 2009-07-20 21:17    [W:0.023 / U:1.924 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site