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
> 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 ha
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 int
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
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
"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)
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 on
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
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
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,
> 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
> 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)
-
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 def
> 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 wh
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
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. Yo
> * 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)
--
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 ke
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
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
20 matches
Mail list logo
