Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Tue, Jul 21, 2009 at 12:28:35AM +0100, Alan Cox wrote: > > I think "tightly integrated" could do with some clarification here. > > qcserial was accepted despite not being functional without a closed > > userspace component - an open one's since been rewritten to allow it to > > It got as far as staging with a good deal of complaint. I am not sure it > would have gotten further unfixed (with my serial/tty maintainers hat > on ;)). That however was about firmware - so a lot less tightly coupled. ? It was merged directly into drivers/usb/serial. > > work. Do we define "tightly integrated" as "likely to cross the GPL > > line" (potentially the case with Poulsbo, not the case with qcserial), > > or is it a pragmatic issue? What about specialised hardware drivers that > > only have closed applications? > > Ultimately - ask a lawyer, ultimately this is a question about works and > copyright boundaries. If the hardware has only some specific proprietary > app then it sounds to me like it's not a general kernel interface so > probably isn't a good interface anyway, let alone what the code may do. I was more wondering about whether we had issues with code that wasn't a GPL concern but still depended on a closed component. -- Matthew Garrett | mj...@srcf.ucam.org -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> I think "tightly integrated" could do with some clarification here. > qcserial was accepted despite not being functional without a closed > userspace component - an open one's since been rewritten to allow it to It got as far as staging with a good deal of complaint. I am not sure it would have gotten further unfixed (with my serial/tty maintainers hat on ;)). That however was about firmware - so a lot less tightly coupled. > work. Do we define "tightly integrated" as "likely to cross the GPL > line" (potentially the case with Poulsbo, not the case with qcserial), > or is it a pragmatic issue? What about specialised hardware drivers that > only have closed applications? Ultimately - ask a lawyer, ultimately this is a question about works and copyright boundaries. If the hardware has only some specific proprietary app then it sounds to me like it's not a general kernel interface so probably isn't a good interface anyway, let alone what the code may do. Alan -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/21 Stephane Marchesin : > 2009/7/20 Thomas Hellström : >> >> Stephane, >> Some comments on how these things has been handled / could be handled. >>> >>> 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? >>> >> >> If there is a serious OS project, I'd start a new DRM driver. >> That's sort of what may happen with openChrome vs via.. >> > > Well, for user space, there can be as many drivers as you want for a > given device. But the DRM policy always was one driver per hardware so > as to avoid confusing people, so what you're proposing is in fact not > possible. In that case, this would even deter a fully open source > driver as it would have to keep the same interface as some (possibly > unsupported) driver. Well with KMS it sort of changes that a small bit, since a KMS driver really isn't required to share old interfaces, since having a KMS enabled kernel will break any userspace that is out there just by setting up the hw different. as long as the old code is still available in the backwards compat manner it should all be fine. We've also had two drm drivers before, i830 and i915 supported a lot of the same hw and it mostly worked, if you looked at it from a kernel perspective. Dave. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/20 Thomas Hellström : > > Stephane, > Some comments on how these things has been handled / could be handled. >> >> 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? >> > > If there is a serious OS project, I'd start a new DRM driver. > That's sort of what may happen with openChrome vs via.. > Well, for user space, there can be as many drivers as you want for a given device. But the DRM policy always was one driver per hardware so as to avoid confusing people, so what you're proposing is in fact not possible. In that case, this would even deter a fully open source driver as it would have to keep the same interface as some (possibly unsupported) driver. >> * 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? >> > > I'd say the DRM driver gets disabled unless fixed. How would we handle that > problem today with, for example, the SiS driver? If no one can fix it it gets killed, yes. I would expect this to happen pretty quickly in fact, in which case the "driver merge/problem found/driver removal" cycle requires more work than it's worth. > >> * 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? >> > > Again, this has been done quite commonly in the past and was easier to get > right with the old drm.git testing ground. Same issue with unmaintained > drivers with OS user-space. Who has actually tested all the drivers when > making such a change? I certainly haven't. The change was left for testing > for a while in drm.git before Dave moved it upstream. > Well, some of us want to be thorough when doing invasive changes, untestable code would prevent such changes (and then we get more of the DRM cruft as a result). And yes, if people do not cooperate on all drivers, this leads to issues in the code. At this point it's not a matter of open source vs closed, but a problem of cooperation. Stephane -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 04:16:20PM +0100, Alan Cox wrote: > > 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! > > The existing policy based on what has been rejected is: > > - If you have something which only works with some non-free tightly > integrated software then we don't accept it > > Examples - GMX500, Intel wireless regulatory daemon. I think "tightly integrated" could do with some clarification here. qcserial was accepted despite not being functional without a closed userspace component - an open one's since been rewritten to allow it to work. Do we define "tightly integrated" as "likely to cross the GPL line" (potentially the case with Poulsbo, not the case with qcserial), or is it a pragmatic issue? What about specialised hardware drivers that only have closed applications? -- Matthew Garrett | mj...@srcf.ucam.org -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
"Andrey Panin" writes: > * Users are still on mercy of binary blob supplier. Will this blob run on > arm ? > Or powerpc ? Or even x86_64 ? Will it be compatible with XOrg X.Y ? > Nobody knows that and there is no gain for users too. Actually there is a loss - users see the kernel (or partial) driver and think it's open source solution. Been there, it wasn't nice at start and even less nice when the thing chose not to work as advertised. This was (is?) also the case with NVidia graphics drivers, I know many people who purchased their cards thinking they are fully open-source (because their drivers had to be "compiled"). -- Krzysztof Halasa -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 11:57:45AM -0400, Christoph Hellwig wrote: > Greg still claims that qcserial could be used by rebooting from Windows, > right? I think any argument that involves us requiring open userspace but allows us to get away with using Windows as a firmware loader is a dubious one :) But yes, it's certainly borderline. I'm not going to argue that it's clearly wrong, and I'm also aware that putting explicit limits on any of this is potentially an invitation for people to try to get as close to the line as they can. > In that it would still be extremly borderline to me, but it's > settled now. We also have various SCSI HBA drivers that can be used > just fine, but contain tons ot ioctls for management tools that aren't > available as open source (or even easily obtainable at all). Personally > I don't think we should merge those unless we have userspace code > available freely, but it's a less urgent issue than merging drivers that > can't be used at all. The DRM modules fall to me exactly into that > category for "specialised hardware drivers that only have closed > applications", and the answer to those should be a clear no. I'd lean in the same direction. -- Matthew Garrett | mj...@srcf.ucam.org -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/21 Thomas Hellström : > Stephane Marchesin wrote: >>> >>> 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! >>> >>> >> >> > > Stephane, > Some comments on how these things has been handled / could be handled. >> >> 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? >> > > If there is a serious OS project, I'd start a new DRM driver. > That's sort of what may happen with openChrome vs via.. > >> * 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? >> > > I'd say the DRM driver gets disabled unless fixed. How would we handle that > problem today with, for example, the SiS driver? > >> * 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? >> > > Again, this has been done quite commonly in the past and was easier to get > right with the old drm.git testing ground. Same issue with unmaintained > drivers with OS user-space. Who has actually tested all the drivers when > making such a change? I certainly haven't. The change was left for testing > for a while in drm.git before Dave moved it upstream. > >> In my opinion, accepting GPL'ed DRM modules that support binary user >> space components is like opening pandora's box. >> >> Stephane >> > > Yeah, drivers supporting binary blobs only is out of the question as it > seems. > > Now's the tricky question how do we handle VIA's patches where they claim > they have an open-source 2D component that exercises all of the DRM module > for EXA render acceleration, and on top of this the 3D binary driver that > apparently uses no additional DRM functionality compared to the 2D > component? > > In the ideal world I'd of course like to see a Chrome9 3D driver based of > the new openChrome drm driver with a modern GPU memory manager, kernel > modesetting and Gallium, but that's a dedicated man-year or more away if / > when someone decides to work on it. > If VIA releases the DDX code to use the DRM code, and it exercises the ioctls then we can add kernel support for the ioctls the DDX uses. If there a bunch of ioctls specific to the 3D driver we should identify them and see if userspace test code is available. I think this is the same as when poulsbo was proposed, if open code uses the interfaces we add them, if not we don't. I'd also prefer a community approach to work more on the new world order and ignore this interface. Dave. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Stephane Marchesin wrote: >> 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! >> >> > > Stephane, Some comments on how these things has been handled / could be handled. > 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? > If there is a serious OS project, I'd start a new DRM driver. That's sort of what may happen with openChrome vs via.. > * 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? > I'd say the DRM driver gets disabled unless fixed. How would we handle that problem today with, for example, the SiS driver? > * 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? > Again, this has been done quite commonly in the past and was easier to get right with the old drm.git testing ground. Same issue with unmaintained drivers with OS user-space. Who has actually tested all the drivers when making such a change? I certainly haven't. The change was left for testing for a while in drm.git before Dave moved it upstream. > In my opinion, accepting GPL'ed DRM modules that support binary user > space components is like opening pandora's box. > > Stephane > Yeah, drivers supporting binary blobs only is out of the question as it seems. Now's the tricky question how do we handle VIA's patches where they claim they have an open-source 2D component that exercises all of the DRM module for EXA render acceleration, and on top of this the 3D binary driver that apparently uses no additional DRM functionality compared to the 2D component? In the ideal world I'd of course like to see a Chrome9 3D driver based of the new openChrome drm driver with a modern GPU memory manager, kernel modesetting and Gallium, but that's a dedicated man-year or more away if / when someone decides to work on it. /Thomas -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
2009/7/21 Peter Zijlstra : > On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote: >> Politics: >> It's true that sometimes some people don't like the code or what it >> does. But when this is the underlying cause of NAK-ing a driver I think >> it's very important that this is clearly stated, instead of inventing >> various random reasons that can easily be argued against. How should the >> driver writer otherwise get it right? Man-years might be spent fixing up >> drivers that will never get upstream anyway. >> >> I think it would help a lot of there was a documented set of driver >> features that were required and sufficient for a DRM driver to go >> upstream. It could look something like >> >> * Kernel coding style obeyed. Passing checkpatch. > > * fully functional GPL user-space driver. > > How can you argue that something as tailor made as a DRM interface can > be used without it being a derived work? For a start the userspace is MIT licensed generally, also with architectures such as gallium3D you can't easily say a driver is derived from the kernel interface. Actually generally the argument is the drm interface would be derived work of the userspace. Kernel hackers aren't lawyers so I cringe whenever one of them says derived work, without understanding that 80-90% of the code is probably in the userspace 3D driver, so proving its derived from a 1000 line kernel interface is where it gets messy, and hence why a number of lawyers for Intel have already come down on thinking it was acceptable and from what I can see are still shipping kernels with an open drm but a closed userspace. So I'm not saying I agree with having these I'm just saying its not your 1000 line regulatory daemon case. Dave. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 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. Stephane -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> Greg still claims that qcserial could be used by rebooting from Windows, > right? In that it would still be extremly borderline to me, but it's qcserial has a firmware loader app nowdays (someone wrote one in April) http://www.codon.org.uk/~mjg59/gobi_loader/ indeed Matthew wrote it 8) -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 04:52:26PM +0100, Matthew Garrett wrote: > I think "tightly integrated" could do with some clarification here. > qcserial was accepted despite not being functional without a closed > userspace component - an open one's since been rewritten to allow it to > work. Do we define "tightly integrated" as "likely to cross the GPL > line" (potentially the case with Poulsbo, not the case with qcserial), > or is it a pragmatic issue? What about specialised hardware drivers that > only have closed applications? Greg still claims that qcserial could be used by rebooting from Windows, right? In that it would still be extremly borderline to me, but it's settled now. We also have various SCSI HBA drivers that can be used just fine, but contain tons ot ioctls for management tools that aren't available as open source (or even easily obtainable at all). Personally I don't think we should merge those unless we have userspace code available freely, but it's a less urgent issue than merging drivers that can't be used at all. The DRM modules fall to me exactly into that category for "specialised hardware drivers that only have closed applications", and the answer to those should be a clear no. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> 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! The existing policy based on what has been rejected is: - If you have something which only works with some non-free tightly integrated software then we don't accept it Examples - GMX500, Intel wireless regulatory daemon. So until there is an open source user and test case for the kernel code it has no place in the kernel (and indeed if the two are closely interconnected and dependent then there are good 'talk to your lawyer' reasons as well) Once there is a useful combination of kernel/user space free software for the card then it makes sense to look at a merge. Until then you don't even know what the final interface will look like and what is actually needed kernel side. The VIA stuff might be a useful basis for that work but that is a when/if anyone ever writes drivers for it. My guess is that if someone cares enough about the hardware they need to get EXA working along with 2D render, then submit the bits the need to do hardware rendering. After that tackle what is needed for 3D - as is happening with the Nvidia drivers and then submit a DRM module for their work. Alan -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Peter Zijlstra wrote: > On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote: > >> Politics: >> It's true that sometimes some people don't like the code or what it >> does. But when this is the underlying cause of NAK-ing a driver I think >> it's very important that this is clearly stated, instead of inventing >> various random reasons that can easily be argued against. How should the >> driver writer otherwise get it right? Man-years might be spent fixing up >> drivers that will never get upstream anyway. >> >> I think it would help a lot of there was a documented set of driver >> features that were required and sufficient for a DRM driver to go >> upstream. It could look something like >> >> * Kernel coding style obeyed. Passing checkpatch. >> > > * fully functional GPL user-space driver. > > How can you argue that something as tailor made as a DRM interface can > be used without it being a derived work? > > FWIW my full vote goes against allowing such thing to happen, and I > think quite a lot of kernel people would agree with me. > > I would hope enough of of them would so that we can stop this from > happening. > > Negative karma points to you for trying to chip away at the spirit of > As stated before this was a suggestion to clarify the field for driver writers. If the documented set of driver features required is fully open-source so be it. Just let people know. /Thomas > Linux. > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Christoph Hellwig wrote: > > > I think you're just trying to push your agenda. > > I think you're just trying to defend your business writing closed source > drivers. Drivers that aren't usable without binary blobs don't have > a business in the kernel tree, and your whining doesn't help it. You'd > be better off spending your time getting proper open drivers done than > defending doing the work to support closed binaries. > 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! /Thomas -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
> * fully functional GPL user-space driver. > > How can you argue that something as tailor made as a DRM interface can > be used without it being a derived work? Our prior policy has been to reject such stuff (both the Intel wireless driver regulatory daemon and the GMX driver) -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On 201, 07 20, 2009 at 03:38:32PM +0200, Thomas Hellstr?m wrote: > Hi! > > It appears that GPL'd DRM drivers for closed-source user-space > clients are becoming more common, and the situation appears to be > causing a lot of unnecessary work from people wanting their drivers > in the mainstream kernel. Arguments against pushing upstream > include. > >* Security. >* User space interface validation and maintainability. >* Politics Why should linux kernel developers care about these drivers at all ? * If such driver is accepted it immediately puts compatibility burden on drm developers without any gain for them. * Users are still on mercy of binary blob supplier. Will this blob run on arm ? Or powerpc ? Or even x86_64 ? Will it be compatible with XOrg X.Y ? Nobody knows that and there is no gain for users too. > Security: > I think from a security point of view, open docs and a thorough > documented security analysis by the driver writer should be > sufficient. This should include: > > 1. In what ways can the GPU access random system pages and how is > user-space prevented from doing that in the driver? > 2. In what ways can the GPU transfer random user data into its own > privileged command stream and, if relevant, how is that prevented > in the driver? > 3. Is the driver capable of maintaining video memory ownership and > protecition? > (Currently not a requirement) > 4. How is user-space prevented from causing the kernel driver to do > unlimited allocations of kernel resources, like buffer objects or > references to them. > > I really don't think an open-source user-space client can add much > more to this. It can perhaps be used to detect obvious big security > flaws but that should be apparent also from the open docs and the > security analysis. > > User-space interface: > Historically driver-specific interfaces have really been up to the > driver writer and when posted for review they receive very little > comments unless there are things like 64/32 bit incompatibilities > etc, but as mentioned on the list, small programs that demonstrate > the use of all interface functions would be desirable, and very > helpful if someone decides to do write an open-source driver. > > Politics: > It's true that sometimes some people don't like the code or what it > does. But when this is the underlying cause of NAK-ing a driver I > think it's very important that this is clearly stated, instead of > inventing various random reasons that can easily be argued against. > How should the driver writer otherwise get it right? Man-years might > be spent fixing up drivers that will never get upstream anyway. > > I think it would help a lot of there was a documented set of driver > features that were required and sufficient for a DRM driver to go > upstream. It could look something like > >* Kernel coding style obeyed. Passing checkpatch. >* short description of underlying driver architecture (GEM / TTM / > Traditional) and future plans >* Security analysis according to the above. >* Open user-space source exercising all functions of the driver or > fully open docs. >* User-space interface description and relation to future plans. > > > Thanks, > /Thomas > > > > > > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, 2009-07-20 at 15:38 +0200, Thomas Hellström wrote: > Politics: > It's true that sometimes some people don't like the code or what it > does. But when this is the underlying cause of NAK-ing a driver I think > it's very important that this is clearly stated, instead of inventing > various random reasons that can easily be argued against. How should the > driver writer otherwise get it right? Man-years might be spent fixing up > drivers that will never get upstream anyway. > > I think it would help a lot of there was a documented set of driver > features that were required and sufficient for a DRM driver to go > upstream. It could look something like > > * Kernel coding style obeyed. Passing checkpatch. * fully functional GPL user-space driver. How can you argue that something as tailor made as a DRM interface can be used without it being a derived work? FWIW my full vote goes against allowing such thing to happen, and I think quite a lot of kernel people would agree with me. I would hope enough of of them would so that we can stop this from happening. Negative karma points to you for trying to chip away at the spirit of Linux. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
On Mon, Jul 20, 2009 at 03:38:32PM +0200, Thomas Hellstr?m wrote: > Hi! > > It appears that GPL'd DRM drivers for closed-source user-space clients > are becoming more common, and the situation appears to be causing a lot > of unnecessary work from people wanting their drivers in the mainstream > kernel. Arguments against pushing upstream include. > >* Security. >* User space interface validation and maintainability. >* Politics There are also useless. > Security: > I think from a security point of view, open docs and a thorough > documented security analysis by the driver writer should be sufficient. > This should include: I think you're just trying to push your agenda. Every closed driver I had access to was an utter piece of rubbish so far, and you'll need the code to prove otherwise. > User-space interface: > Historically driver-specific interfaces have really been up to the > driver writer and when posted for review they receive very little > comments unless there are things like 64/32 bit incompatibilities etc, > but as mentioned on the list, small programs that demonstrate the use of > all interface functions would be desirable, and very helpful if someone > decides to do write an open-source driver. Unless you actually have a generic userspace working with all drm drivers you'll also have a very hard time claiming it's not a derived work of the kernel drm. Nevermind code not having open userspace is impossible to test properly. > Politics: > It's true that sometimes some people don't like the code or what it > does. But when this is the underlying cause of NAK-ing a driver I think > it's very important that this is clearly stated, instead of inventing > various random reasons that can easily be argued against. How should the > driver writer otherwise get it right? Man-years might be spent fixing up > drivers that will never get upstream anyway. I think you're just trying to defend your business writing closed source drivers. Drivers that aren't usable without binary blobs don't have a business in the kernel tree, and your whining doesn't help it. You'd be better off spending your time getting proper open drivers done than defending doing the work to support closed binaries. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
