---------- Forwarded message ----------
From: Timothy Meade <[email protected]>
Date: Thu, Jul 1, 2010 at 8:38 PM
Subject: Closed source userspace graphics drivers with an open source
kernel component
To: Saravana Kannan <[email protected]>
Cc: LKML <[email protected]>, dri-devel
<[email protected]>, [email protected],
[email protected]
On Thu, Jul 1, 2010 at 8:18 PM, Saravana Kannan <[email protected]> wrote:
>
> Dave Airlie wrote:
>>
>> This is more about initial development stages. We maintain kernel
>> API/ABI for all in-tree drivers, however before we put a driver into
>> mainline, we usually need to redo the crazy interfaces that vendors
>> have come up with. Like 32/64 alignment, passing userspace addresses
>> into the kernel, passing phy addresses to userspace etc. If the
>> userspace binary is closed that process becomes next to impossible.
>
> My 2 cents:
> I think we should leave the onus of fixing the userspace to work with the sane kernel API with the entity trying to get their drivers into the kernel. I think it's a better approach (as in, more likelihood of getting device support) than saying, we will only allow fully open sourced kernel drivers.
>
> -Saravana
> --
> To unsubscribe from this list: send the line "unsubscribe linux-arm-msm" in
> the body of a message to [email protected]
> More majordomo info at ?http://vger.kernel.org/majordomo-info.html
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.
I hope those making the decision will take this into consideration.
--
Timothy Meade (tmzt on freenode)
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.
> 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.
also, they seem to do it quite wrong way. i.e. much simpler would be to
just implement regular, open driver , and implement additional crypto
mechanism in chipset itself, allowing to use simple userspace program
sending certified keys allowing GPU to operate.
if key is not available and device/driver not paid/registered, then
GPU would simply lock itself , similiar to pre-paid designs from
company whose name should not be spoken aloud.
also certain functionality could be ordered with same chip structure,
i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
with user buying proper 'entry level' pre-paid code set from manufacturer.
this would provide quite same functionality (profit), without impacting
open-source projects like Xorg with unnessesary complications.
--
Piotr Gluszenia Slawinski wrote:
>> 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.
>
> also, they seem to do it quite wrong way. i.e. much simpler would be to
> just implement regular, open driver , and implement additional crypto
> mechanism in chipset itself, allowing to use simple userspace program
> sending certified keys allowing GPU to operate.
> if key is not available and device/driver not paid/registered, then
> GPU would simply lock itself , similiar to pre-paid designs from
> company whose name should not be spoken aloud.
>
> also certain functionality could be ordered with same chip structure,
> i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
> with user buying proper 'entry level' pre-paid code set from manufacturer.
>
> this would provide quite same functionality (profit), without impacting
> open-source projects like Xorg with unnessesary complications.
Pardon me for intruding in this discussion, but I'm astonished that you
actually find what you posted to be acceptable. If I pay for a piece of
hardware, I have the right to use it. Requiring certified keys before it
performs the function for which it was purchased is pure nonsense.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
> Piotr Gluszenia Slawinski wrote:
>> > 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.
>>
>> also, they seem to do it quite wrong way. i.e. much simpler would be to
>> just implement regular, open driver , and implement additional crypto
>> mechanism in chipset itself, allowing to use simple userspace program
>> sending certified keys allowing GPU to operate.
>> if key is not available and device/driver not paid/registered, then
>> GPU would simply lock itself , similiar to pre-paid designs from
>> company whose name should not be spoken aloud.
>>
>> also certain functionality could be ordered with same chip structure,
>> i.e. framebuffer, unaccelerated 2d, accel 2d, 3d, etc.
>> with user buying proper 'entry level' pre-paid code set from manufacturer.
>>
>> this would provide quite same functionality (profit), without impacting
>> open-source projects like Xorg with unnessesary complications.
>
> Pardon me for intruding in this discussion, but I'm astonished that you
> actually find what you posted to be acceptable. If I pay for a piece of
> hardware, I have the right to use it. Requiring certified keys before it
> performs the function for which it was purchased is pure nonsense.
in this context it is more lease than purhase, similiar to situation
when you buy cellphone, but you are limited by the sim card to access
networks, and sometimes even own adress book (when your account is
drained, your adress book stored on sim data card is locked).
i do not claim such practices are convient for users, yet they are
very convient for hardware vendors, and it seems more 'open cards' play
which seems more clear to user than situation in which you need binary
blobs which can contain everything from rootkit to actual crypto routine
(i.e. to prevent driver running on 'non original' clone video cards made
by competitor company) running with ROOT privileges on the computers of
users being told it is Only Way (tm) to make given company profit and
survive, while providing some functionality as a trade.
so to resume such solution - one gets fair information about to which
extent company allows usage of hardware sold to user (without messy 'end
user license' implied on binary drivers) , and can perform clear
decision - either buying 'secure' and 'genuinely original' video card
with options one needs and is able to pay for (which includes
software development price) , or goes for more 'open' solutions.
mind you most of hardware vendors do NOT want you to purhase
hardware, at best they want LICENSE you to use it for specific
purpose, and specific period. the wish of yours to freely use
hardware does not represent accurate wish of casual users ,
which do not care about freedom as long as hardware allows them
to perform specific task.
either way imho mixing those two attitudes is erroneus,
as it creates confusion and beliefs that some hardware is intended
for free use, and in same time that some software should provide
infrastructure to limit safety and freedom of users.
also it leads to development of BOTH. the sooner those two will
be separated, the sooner alternatives will be created,
and most importantly RECOGNIZED by market.
--
Hi!
> >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.
>
> also, they seem to do it quite wrong way. i.e. much simpler would be
> to just implement regular, open driver , and implement additional
> crypto
> mechanism in chipset itself, allowing to use simple userspace program
> sending certified keys allowing GPU to operate.
What is going on there? Does msm actually use crypto to prevent you
from use hardware you bought?
Are the keys device-specific? What prevents me from
reverse-engineering their binary and publishing them?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Wed, Jul 14, 2010 at 9:24 AM, Pavel Machek <[email protected]> wrote:
> Hi!
>
>> >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.
>>
>> also, they seem to do it quite wrong way. i.e. much simpler would be
>> to just implement regular, open driver , and implement additional
>> crypto
>> mechanism in chipset itself, allowing to use simple userspace program
>> sending certified keys allowing GPU to operate.
>
> What is going on there? Does msm actually use crypto to prevent you
> from use hardware you bought?
>
> Are the keys device-specific? What prevents me from
> reverse-engineering their binary and publishing them?
> ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Pavel
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
Hi Pavel. No I think that was meant to be theoretical/hypothetical.
There's no crypto or device key as such, this hardware is much like
any other that requires firmware to function.
I think the issue is broader than that. The question seems to be
whether an open API/ABI can be specified between an open kernel driver
and a closed userspace driver that is required to perform a subset of
the total functionality, in this case, certain GL and 3D primitives.
The other functions, 2d, the ability to bind a texture to a simple
poly, etc. can be potentially accomplished with an open source driver
and development of a radeonhd or avivo based driver in parallel. But
that would require developers to agree on an API that can be stablised
and standardized between Android Xorg 2d driver and any potential 3d
driver, where the developers of closed source components must ensure
they remain compatible with whatever direction the open driver takes.
--
Timothy Meade
tmzt #htc-linux