From: Dave Airlie <airlied@redhat.com>
To: Timothy Meade <zt.tmzt@gmail.com>
Cc: Saravana Kannan <skannan@codeaurora.org>,
linux-arm-msm@vger.kernel.org,
LKML <linux-kernel@vger.kernel.org>,
dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: Closed source userspace graphics drivers with an open source kernel component
Date: Fri, 02 Jul 2010 12:46:36 +1000 [thread overview]
Message-ID: <1278038796.19705.21.camel@clockmaker-el6> (raw)
In-Reply-To: <AANLkTimiNKRabIDCLvRwxVfdwuvt76PbDuTn2RocZLVG@mail.gmail.com>
On Thu, 2010-07-01 at 20:42 -0400, Timothy Meade wrote:
> ---------- Forwarded message ----------
> Hello. I've been working with the developers on the htc-linux project
> and following the progress of Android on MSM devices closely for a few
> years. I've been excitied to see DRM/DRI replace PMEM and the Android
> specific interfaces be replaced with more Linux-like ones. The Xorg
> driver from Qualcomm uses this same interface for 2D and it's possible
> that Android will take the same approach, though it uses 3D and GLES
> as a type of abstraction layer for surfaceflinger. This allows for a
> closed 3D driver with an open command submission layer that is in
> itself not that different from the split for ATI devices using
> radeonhd. I say this because the alternative for these devices is a
> fully closed binary and secrecy surrounding the graphics layers that
> ensures that only the OS that ships with the device can ever really be
> used and preventing those non-coorporate developers as myself from
> utilising GPL code the way we want or even usuing are own cell phones
> (in this case). I would choose a fully open, X based OS even if that
> meant only having 2D drivers, but I know that Quic and others aren't
> going to develop just a (accelerated) 2D driver, not the kernel
> components or userspace but instead rely on the same GLES layer that
> Android uses, essentially making X and open environments a second
> class citizen on modern mobile hardware.
The thing is you are prevented from using the GPU the way you want,
telling you how to send commands and get irqs from a device but not
telling you what those commands means is limiting you. So you can use it
a framebuffer device, you can do that with a 500 line fbdev driver most
likely, we don't need the maintainer burden of the other 5000 lines of
code that are only in the driver to service some 3D userspace binary
blob.
The radeon example is pointless since all pieces in that system are open
even if AMD can't/won't disclose how certain parts of the GPU work, we
have access to nearly all the functionality, we control all the open
pieces and if someone reverse engineers it, AMD have to accept it.
There is no point supporting companies that give you a little bit of
information in exchange they want the support that being in a mainline
kernel gives. Its an unfair exchange of knowledge and time, and if they
claim they have to make a profit then its even more unfair.
Dave.
next prev parent reply other threads:[~2010-07-02 2:46 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-01 22:10 Closed source userspace graphics drivers with an open source kernel component Dave Airlie
2010-07-01 22:36 ` Dave Airlie
2010-07-01 22:51 ` Daniel Walker
2010-07-01 22:57 ` Dave Airlie
2010-07-01 23:29 ` Daniel Walker
2010-07-01 23:37 ` Dave Airlie
2010-07-02 0:08 ` Daniel Walker
2010-07-02 0:13 ` Dave Airlie
2010-07-02 0:18 ` Saravana Kannan
[not found] ` <AANLkTilsqmCZwLUNJhvDKkralHQZzlRV3ZxaIGbt9-xB@mail.gmail.com>
[not found] ` <AANLkTinvzJrx4AqgWYuMg66Djf-snouLQZE7wI9Bu0Kv@mail.gmail.com>
2010-07-02 0:42 ` Timothy Meade
2010-07-02 2:46 ` Dave Airlie [this message]
2010-07-02 3:01 ` Piotr Gluszenia Slawinski
2010-07-02 4:54 ` Howard Chu
2010-07-02 6:52 ` Piotr Gluszenia Slawinski
2010-07-14 13:24 ` Pavel Machek
2010-07-16 0:42 ` Tim HRM
2010-07-01 23:51 ` Piotr Gluszenia Slawinski
2010-07-02 1:27 ` Corbin Simpson
2010-07-02 7:48 ` Christoph Hellwig
2010-07-02 9:58 ` Luc Verhaegen
2010-07-02 10:15 ` Christoph Hellwig
2010-07-02 11:12 ` Luc Verhaegen
2010-07-02 11:26 ` Dave Airlie
2010-07-02 10:23 ` Dave Airlie
2010-07-02 11:10 ` Luc Verhaegen
2010-07-02 11:53 ` Dave Airlie
2010-07-02 12:07 ` "C. Bergström"
2010-07-02 14:45 ` Xavier Bestel
2010-07-02 15:03 ` "C. Bergström"
[not found] ` <AANLkTinZXHi_mbmsX1HTzbMNjQx7j0rbEfTKSoz-02CF@mail.gmail.com>
2010-07-04 7:27 ` Dave Airlie
2010-07-04 11:03 ` Theodore Tso
2010-07-04 15:37 ` Matthew Garrett
2010-07-04 20:05 ` Dave Airlie
2010-07-02 14:01 ` Anton Vorontsov
2010-07-03 0:41 ` Ian Romanick
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=1278038796.19705.21.camel@clockmaker-el6 \
--to=airlied@redhat.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=skannan@codeaurora.org \
--cc=zt.tmzt@gmail.com \
/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