linux-kernel - Re: Closed source userspace graphics drivers with an open source kernel component

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 02 Jul 2010 12:46:36 +1000
From:	Dave Airlie <airlied@...hat.com>
To:	Timothy Meade <zt.tmzt@...il.com>
Cc:	Saravana Kannan <skannan@...eaurora.org>,
	linux-arm-msm@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>,
	dri-devel <dri-devel@...ts.freedesktop.org>
Subject: Re: Closed source userspace graphics drivers with an open source 
 kernel component

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.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/