Announcement

Collapse
No announcement yet.

Radeon OpenGL 2.0 support

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

  • #51
    Mostly DRM - the bane of my existence

    All of the other OSes require robust Digital Rights Management implementations, and that requires DRM support all through the driver stack. In principle open source and DRM are not mutually exclusive, but today they are.
    Test signature

    Comment


    • #52
      I can't imagine any way that the DVD or Blu-Ray DRM requirements can be compatible with open source. How on earth is an open source stack supposed to "robustly" implement things like region codes or the Image Constraint Token, if a user can simply compile out these antifeatures?

      Comment


      • #53
        Originally posted by Alex W. Jackson View Post
        I can't imagine any way that the DVD or Blu-Ray DRM requirements can be compatible with open source. How on earth is an open source stack supposed to "robustly" implement things like region codes or the Image Constraint Token, if a user can simply compile out these antifeatures?
        Well, for the region codes for example, you simply force the hardware to be placed in a region before it will function properly. And then you limit the number of times the region can be changed, so that the software can't just change it to whatever is being played.

        So that kind of DRM can work with OSS, but only by moving all the secure stuff out of the software and into the hardware.

        Comment


        • #54
          Originally posted by Alex W. Jackson View Post
          I can't imagine any way that the DVD or Blu-Ray DRM requirements can be compatible with open source. How on earth is an open source stack supposed to "robustly" implement things like region codes or the Image Constraint Token, if a user can simply compile out these antifeatures?
          I'm about the furthest thing from a crypto expert, but the quick answer is that you need *something* that can't be edited, it just doesn't have to be in the driver stack -- usually either firmware in the BD drive or a certified & digitally signed binary player app.

          The lower levels of the stack still need to be certified by a third party at a binary level, and the "secure" player/firmware cryptographically validates that it is talking to a certified driver stack -- the "open source" part of it is that the source code for the driver stack can be made visible without weakening the robustness of the implementation.

          All the papers I have seen over the years go as far as demonstrating the principle but I haven't seen any real world implementations yet.

          The chicken-and-egg question is whether Linux's market share can grow enough to justify a separate, DRM-free proprietary driver (which then could be at least partially open sourced) without having to offer certified playback of protected content to obtain that market share (which would require DRM anyways).
          Test signature

          Comment


          • #55
            Originally posted by bridgman View Post
            The lower levels of the stack still need to be certified by a third party at a binary level, and the "secure" player/firmware cryptographically validates that it is talking to a certified driver stack -- the "open source" part of it is that the source code for the driver stack can be made visible without weakening the robustness of the implementation.
            What you're describing isn't open source. It may be "shared source" or whatever Microsoft's bullshit marketing phrase is, but if you can't modify and recompile and have it still work, then it isn't open source.

            DRM regimes that mandate antifeatures in software are, by nature, directly antithetical to open source.
            Last edited by Alex W. Jackson; 14 October 2009, 01:09 AM.

            Comment


            • #56
              I deliberately used "open source" rather than "free". DRM regimes that mandate antifeatures in software are, by nature, directly antithetical to free software. The term "open source" is more flexible. The generally accepted definition for "open source" is the OSI's Open Source Definition, which does not appear to prohibit an external certification mechanism granting additional rights to users of certified binaries. It's possible that GPLv2 could allow it as well, although GPLv3 tries hard to prevent any kind of DRM.

              That said, we are not talking about the ability to recompile the full DRM-enabled driver anyways. The DRM-enabled driver would be for "one of those other OSes". We are talking about the ability to expose the portions of the shared code which are used by the Linux driver, where DRM is *not* implemented.

              You could recompile the *Linux* driver and have it work, you just couldn't recompile the driver for the *other* OS and have it work -- but you wouldn't have full source code for that driver anyways, just for the portion which was shared with Linux.

              The goal of the "open source DRM implementation" (if it ever turned out to be possible) would be to let us share code between drivers for Linux and for DRM-enabled OSes as we do today, but also to let us provide source code for the complete Linux kernel driver without putting our DRM implementation on other OSes at risk.

              Anyways, this is all hypothetical and I haven't heard of any recent progress in that area; I just mentioned the possiblity for completeness and to avoid all the "open source DRM is possible, see xxx research paper" flames I usually get when discussing DRM on a public forum
              Last edited by bridgman; 14 October 2009, 01:56 AM.
              Test signature

              Comment


              • #57
                Originally posted by bridgman View Post
                The generally accepted definition is the OSI's Open Source Definition, which does not appear to prohibit an external certification mechanism granting additional rights to users of certified binaries. It's possible that GPLv2 could allow it as well, although GPLv3 tries hard to prevent any kind of DRM.
                It'd be more precise to say that the GPLv3 tries its best to prohibit "granting additional rights to users of certified binaries". I like that phrasing.

                Originally posted by bridgman
                You could recompile the *Linux* driver and have it work, you just couldn't recompile the driver for the *other* OS and have it work -- but you wouldn't have full source code for that driver anyways, just for the portion which was shared with Linux.

                The goal of the "open source DRM implementation" (if it ever turned out to be possible) would be to let us share code between drivers for Linux and for DRM-enabled OSes as we do today, but also to let us provide source code for the complete Linux kernel driver without putting our DRM implementation on other OSes at risk.
                If that's the case, then why do you keep bringing up the idea of "authorized" Linux BD playback in this and other threads? As you admit, that would require "tivoization" of, at a minimum, the player application, the entire driver stack, and probably the entire Linux kernel. At that point you might as well just be running OS X.

                Comment


                • #58
                  Originally posted by Alex W. Jackson View Post
                  If that's the case, then why do you keep bringing up the idea of "authorized" Linux BD playback in this and other threads?
                  I didn't, other than to the extent it was part of the answer to questions I was being asked. The problem is that the answer to most of the simple "why don't you do XYZ" questions is "DRM", and the answer to the follow-on questions usually touches on an OEM-friendly BD playback solution in one way or another.

                  I was asked why we couldn't open up source code of drivers for other OSes. My response was :

                  Mostly DRM - the bane of my existence. All of the other OSes require robust Digital Rights Management implementations, and that requires DRM support all through the driver stack. In principle open source and DRM are not mutually exclusive, but today they are.
                  You then challenged the statement about DRM and open source not being mutually exclusive in principle, and i gave you a summary of how it might work in principle. That left a number of possible approaches floating open, and I tried to resolve them all as a set :

                  - if we were to open source the Linux kernel driver while sharing code(the original question), the other option would be to write a completely different kernel driver for Linux, but with the current market share and lack of OEM preload business that isn't really viable.

                  - a significant increase in consumer PC Linux market share could justify writing a DRM-free open source kernel driver for fglrx, but most of the customer feedback we get ties significant Linux market share growth to availability of a "legal for OEM sale" BD playback system, which would mean that writing a separate DRM-free kernel driver wouldn't make sense even if the Linux market share *did* grow.

                  - the only scenario that could justify a fully open source kernel driver for fglrx is a significant (say 4-fold) consumer PC market share increase *without* BD or other protected content playback, which most market feedback says is unlikely.

                  The combination of these points covers the major options for providing a fully open kernel driver in the current market -- which was the "original original" question. Only one scenario works - significant consumer PC market share growth for Linux without requiring OEM-friendly BD playback.

                  It's all connected
                  Last edited by bridgman; 14 October 2009, 02:43 AM.
                  Test signature

                  Comment


                  • #59
                    Originally posted by agd5f View Post
                    Apps are supposed to check if the driver supports an extension before using it.
                    Great.

                    Thats exactly why "wine" doesn't support oss radeon driver anymore.

                    wined3d_guess_vendor Received unrecognized GL_VENDOR "DRI R300 Project".

                    Comment


                    • #60
                      Originally posted by Mr_Ed View Post
                      Great.

                      Thats exactly why "wine" doesn't support oss radeon driver anymore.

                      wined3d_guess_vendor Received unrecognized GL_VENDOR "DRI R300 Project".
                      You need to update mesa. Newer versions report the vendor like this:

                      OpenGL renderer string: Mesa DRI R300 (R420 5D4F) 20090101 TCL DRI2

                      Comment

                      Working...
                      X