From: Alan Cox <alan@lxorguk.ukuu.org.uk>
To: "Thomas Hellström" <thomas@shipmail.org>
Cc: Christoph Hellwig <hch@infradead.org>,
DRI <dri-devel@lists.sourceforge.net>,
Linux Kernel list <linux-kernel@vger.kernel.org>
Subject: Re: DRM drivers with closed source user-space: WAS [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Date: Mon, 20 Jul 2009 16:16:20 +0100 [thread overview]
Message-ID: <20090720161620.7b027f8d@lxorguk.ukuu.org.uk> (raw)
In-Reply-To: <4A648718.9000709@shipmail.org>
> 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
next prev parent reply other threads:[~2009-07-20 15:15 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-07-20 13:38 Thomas Hellström
2009-07-20 13:58 ` Christoph Hellwig
2009-07-20 15:02 ` Thomas Hellström
2009-07-20 15:16 ` Alan Cox [this message]
2009-07-20 15:52 ` Matthew Garrett
2009-07-20 15:57 ` Christoph Hellwig
2009-07-20 16:02 ` Matthew Garrett
2009-07-20 16:37 ` Alan Cox
2009-07-20 23:28 ` Alan Cox
2009-07-20 23:33 ` Matthew Garrett
2009-07-20 19:13 ` Stephane Marchesin
2009-07-20 20:19 ` Thomas Hellström
2009-07-20 20:43 ` Dave Airlie
2009-07-20 21:40 ` Stephane Marchesin
2009-07-20 22:31 ` Dave Airlie
2009-07-20 14:06 ` Peter Zijlstra
2009-07-20 14:52 ` Alan Cox
2009-07-20 15:07 ` Thomas Hellström
2009-07-20 19:51 ` Dave Airlie
2009-07-20 14:09 ` Andrey Panin
2009-07-20 19:03 ` Krzysztof Halasa
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20090720161620.7b027f8d@lxorguk.ukuu.org.uk \
--to=alan@lxorguk.ukuu.org.uk \
--cc=dri-devel@lists.sourceforge.net \
--cc=hch@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=thomas@shipmail.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome