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.
* 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)
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
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
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
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
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)
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
2009/7/21 Peter Zijlstra pet...@infradead.org:
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
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
Andrey Panin pa...@centrinvest.ru 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
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
2009/7/20 Thomas Hellström tho...@shipmail.org:
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
2009/7/21 Stephane Marchesin marche...@icps.u-strasbg.fr:
2009/7/20 Thomas Hellström tho...@shipmail.org:
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
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
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
16 matches
Mail list logo
