A line in the sand for graphics drivers
At a first glance, the announcement of a 2D/3D driver for Qualcomm "ES 3D" graphics cores (found in the Snapdragon processor which, in turn, is found in a number of high-end smartphones) seems like a good thing. Graphics support for this core is one of the binary blobs which is necessary to run Android on that processor, and it seemed like Qualcomm was saying the right things:
Advice and comment is what he got. The problem is that, while the kernel driver is GPL-licensed, it is only a piece of the driver. The code which does the real work of making 3D function on that GPU runs in user space, and it remains locked-down and proprietary. Dave Airlie, the kernel graphics maintainer, made it quite clear what he thinks of such drivers:
If you aren't going to create an open userspace driver (either MIT or LGPL) then don't waste time submitting a kernel driver to me.
Dave's message explains his reasoning in detail; little of it will be new to most LWN readers. He is concerned about possible licensing issues and, at several levels, about the kernel community's ability to verify the driver and to fix it as need be. Dave has also expressed his resentment on how the mobile chipset vendors are getting great value from Linux but seem to be entirely unwilling to give back to the kernel they have come to depend on so heavily.
This move may strike some people as surprising. There has been a lot of pressure to get Android-related code into the mainline, but now an important component is being rejected - again. The fact that user-space code is at issue is also significant. The COPYING file shipped with the kernel begins with this text:
Normally, kernel developers see user space as a different world with its own rules; it is not at all common for kernel maintainers to insist on free licensing for user-space components. Dave's raising of licensing issues might also seem, on its face, to run counter to the above text: he is saying explicitly that closed user-space graphics drivers might be a work derived from the kernel and, thus, a violation of the GPL. These claims merit some attention.
The key text above is "normal system calls." A user-space graphics driver does not communicate with its kernel counterpart with normal system calls; it will use, instead, a set of complex operations which exist only to support that particular chipset. The kernel ABI for graphics drivers is not a narrow or general-purpose interface. The two sides are tightly coupled, a fact which has made the definition of the interface between them into a difficult task - and the maintenance of it almost as hard. While a program using POSIX system calls is clearly not derived from the kernel, the situation with a user-space graphics driver is not nearly so clear.
It should also be pointed out that, while the kernel community does not normally try to dictate licensing in user space, that community has also never felt bound to add interfaces for the sole use of proprietary code. The resistance to the addition of hooks for anti-malware programs is a classic example.
But licensing is not the only issue here. In a sense, user-space 3D graphics drivers are really kernel components which simply happen to be running in a separate address space. They necessarily have access to privileged functionality, and they must program a general-purpose processor (the GPU) with the ability to easily hose the system. Without the user-space component, the kernel will not function well. Like other pieces of the kernel, the full 3D driver must be carefully examined to be sure that there are no security problems, fatal bugs, or portability issues. The kernel developers must be able to make changes to the kernel-side driver with full knowledge of what effect those changes will have on the full picture. A proprietary user-space driver clearly makes all of this more difficult - if not impossible.
User-space binary blob drivers also miss out on many of the important benefits of the free software development process. They will contain bugs and a great deal of duplicated code.
What Dave (and others) are clearly hoping is that, by pushing back in this way, they will be able to motivate vendors to open up their user-space drivers as well. The history in this regard is encouraging, but mixed. Over time, hardware vendors have generally come to realize that the value they are selling is not in the drivers and that they can make their lives easier by getting their code out into the open. What did it gain all of those wireless networking vendors to implement and maintain their own 802.11 stacks? One can only imagine that they must be glad to be relieved of that burden. But getting them to that point generally required pressure from the kernel development community.
Hopefully, this pressure will convince at least some mobile 3D vendors to open up as well. That pressure would be increased and made far more effective if at least some device manufacturers would insist on free software support for the components they use. There are companies working in this area which make a lot of noise about their support for Linux. They could do a lot to make Linux better by insisting on that same support from their suppliers.
Over the years, we have seen that pushing back against binary-only drivers
has often resulted in changes for the better; we now have free support for
a lot of hardware which was once only supported by proprietary drivers.
Some vendors never relent, but enough usually have that the recalcitrant
ones can simply be routed around. One shudders to think about what our
kernel might look like now had things not gone that way. The prevalence of
binary-only drivers in the mobile space shows that this fight is not done,
though. 3D graphics drivers are unique in many aspects, including their
use of user-space components. But, if we want to have a free kernel in the
coming years, we need to hope that they will be subject to the same
pressures.
| Index entries for this article | |
|---|---|
| Kernel | Device drivers/Graphics |
Posted Jul 5, 2010 13:52 UTC (Mon)
by Baylink (guest, #755)
[Link] (11 responses)
Has anyone ever put a finger on the assertions I've seen made in some places: that the vendors won't open that code because it has patent or copyright violations in it, and they know it, and they don't want to get busted...?
Posted Jul 5, 2010 14:35 UTC (Mon)
by tzafrir (subscriber, #11501)
[Link] (9 responses)
As for patents: what would be the problem with releasing the source? What secret would it reveal? It's patently clear that patents can not cover trade secrets, right?
Posted Jul 5, 2010 14:39 UTC (Mon)
by Baylink (guest, #755)
[Link] (4 responses)
Posted Jul 9, 2010 9:57 UTC (Fri)
by yoe (guest, #25743)
[Link] (3 responses)
It becomes one if you violate someone's patent knowingly; but proving that you knew about something at some distant point in the past is rather hard.
Posted Jul 9, 2010 10:21 UTC (Fri)
by __alex (guest, #38036)
[Link] (1 responses)
Posted Dec 27, 2010 15:11 UTC (Mon)
by ksandstr (guest, #60862)
[Link]
Posted Jul 9, 2010 17:14 UTC (Fri)
by njs (subscriber, #40338)
[Link]
Everyone who writes some software is violating other people's patents; the problem is if one of those patent owners notices and can sue you.
Posted Jul 5, 2010 14:52 UTC (Mon)
by ernstp (guest, #13694)
[Link] (3 responses)
Posted Jul 5, 2010 15:36 UTC (Mon)
by drag (guest, #31333)
[Link] (2 responses)
They have contractual obligations with other vendors to keep some aspects of their hardware secret. This is due to the DRM requirements they have to face. This is simply part of the reality of being a graphics hardware vendor in this day in age.
Patent issues are another one.
Copyrights can be a issue, but it depends on the vendors and how much they contract out to other businesses.
Trade secrets are another issue. Between ATI vs Nvidia they make or break sales by the quality of their windows drivers. That is simply a fact and is another aspect of business that cannot be escaped.
Those issues are going to be big ones.
---------------------
Writing new open source drivers from scratch, while combined with not documenting certain aspects of the video cards, can avoid most of those issues except patents.
Posted Jul 5, 2010 16:14 UTC (Mon)
by smurf (subscriber, #17840)
[Link] (1 responses)
DRM implies that somewhere there's encrypted / obfuscated content which some piece of code and/or hardware decrypts before displaying, and that said code needs to be coupled to the displaying hardware -- tightly enough that one cannot just capture the output.
Hardware coupling is obviously not a problem in a smartphone (unlike HDMI). That leaves the actual de-obfuscating part of the source code, which is easily removed from any otherwise-open-source driver program.
Posted Jul 5, 2010 16:20 UTC (Mon)
by drag (guest, #31333)
[Link]
I think that is a poor assumption to make. How many PowerVR video devices are used in set-top boxes, televisions, and other devices? I don't know the answer, but it's certainly a large number of devices.
Plus there are phones that do actually have HDMI output, many of those that do are Android devices.
Unfortunately there is plenty of DRM in cell-phone and ARM-style devices.
> encrypted / obfuscated
Yeah. DRM implies Obfuscation really only. Encryption is usually used as part of the process because it's very effective in terms of protection during transport, but it's useless as a mechanism on the actual end user's device itself. So DRM depends entirely on obfuscation to work properly.
DRM is much less of a issue now then it's been in the past, but the effects of it is going to linger on for some years.
Posted Jul 5, 2010 21:03 UTC (Mon)
by airlied (subscriber, #9104)
[Link]
The only thing that might be an issue is the video decode hardware, and I'm willing to accept that maybe they can't always release source code to the MPEG4 patent licenses etc, but generally in a lot of those systems it just a hw video decoder, so they aren't violating anything in sw if they just provide an API.
Posted Jul 5, 2010 14:24 UTC (Mon)
by fuhchee (guest, #40059)
[Link] (1 responses)
Posted Jul 5, 2010 14:34 UTC (Mon)
by jrn (subscriber, #64214)
[Link]
Posted Jul 5, 2010 14:48 UTC (Mon)
by avik (guest, #704)
[Link] (35 responses)
Posted Jul 5, 2010 15:04 UTC (Mon)
by hummassa (guest, #307)
[Link] (25 responses)
I think it's right, for someone who volunteers to maintain that part of the kernel tree, to demand anything she seems fit to demand that will make possible to do said maintenance, before she merges some patch from someone.
A closed driver has the potential make that maintenance difficult (or even impossible), so...
Posted Jul 5, 2010 15:38 UTC (Mon)
by kirkengaard (guest, #15022)
[Link]
The trouble, as was mentioned, is that this isn't just an interface. We have a boatload of interfaces. I think one of the good comparisons is sound drivers. There are quite a few high-end cards that have chip drivers in ALSA, but you use JACK and some other userspace programs to get full function out of them. But the drivers are complete and perform properly (modulo some tinkering) for the chips they drive, and the userspace components sit over the driver or work through it. We're talking instead about half of a driver.
If the submitter wishes the driver to be in the kernel, it is perfectly appropriate for the developer to advise them that the whole driver needs to be open. One way to comply might be to document and re-engineer the kernel component in order to develop a compliant userspace component; another might be to write an all-kernelspace driver; another might be to rip out what "must" be binary blob for now and open everything else -- but only as a first step. I doubt that throwing documentation over the wall will make it acceptable as-is.
Posted Jul 5, 2010 16:10 UTC (Mon)
by ebiederm (subscriber, #35028)
[Link] (23 responses)
A maintainer can ask for too much, and that is why in Linux there is always the possibility to route around a maintainer. Not that this happens often.
In this case one of the primary complaints is poor userspace ABI design, and that is always a valid issue to push back on. Even the most temporary, transient and little used ABIs requires years to phase out.
Overall it appears to be a good thing this conversation is happening, and I hope this can get settled before too much more time passes.
Posted Jul 5, 2010 16:41 UTC (Mon)
by njs (subscriber, #40338)
[Link] (22 responses)
...Huh, I thought it was pretty obvious that they were speaking in general, and the use of, say, alternating gender pronouns for generics is very common.
Do you make this comment every time someone uses a generic "he"?
Posted Jul 5, 2010 23:53 UTC (Mon)
by hummassa (guest, #307)
[Link] (21 responses)
Posted Jul 6, 2010 1:53 UTC (Tue)
by csamuel (✭ supporter ✭, #2624)
[Link] (15 responses)
Posted Jul 6, 2010 3:38 UTC (Tue)
by njs (subscriber, #40338)
[Link]
They all have their advantages and disadvantages, but I was more struck at the suggestion that using "she" was illegitimate, when in actual usage it plainly isn't.
Posted Jul 6, 2010 9:25 UTC (Tue)
by rsidd (subscriber, #2582)
[Link] (13 responses)
Posted Jul 6, 2010 10:44 UTC (Tue)
by nix (subscriber, #2304)
[Link] (7 responses)
Posted Jul 6, 2010 10:54 UTC (Tue)
by rsidd (subscriber, #2582)
[Link] (6 responses)
Of course, you can use plural they if you make all references plural. This is usually awkward and sometimes impossible.
Posted Jul 6, 2010 11:36 UTC (Tue)
by nye (subscriber, #51576)
[Link]
Possibly you should have looked it up before proceeding.
When you talk about using the 'plural they', you are of course obliquely referring to the fact that 'they' remains morphologically plural in all (correct) uses, however its usage to refer to a singular subject is well established.
It has been the preferred style for decades, an accepted style for centuries, and an existing style in English since so long ago that the language is barely recognisable.
If you can present an example sentence where using 'he' or 'she' is grammatically correct, but 'they' is not, then I would be interested to hear it.
Posted Jul 6, 2010 11:56 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (2 responses)
"Singular they", as used by authors from Shakespeare onwards, is things like "they see fit" and "they merge a patch". It's simply the same pattern as "singular you"; or art thou one of the people who insisteth that "you" must be reserved for the plural form, and who joketh about "you sees fit" and "you merges a patch"?
Posted Jul 20, 2010 17:10 UTC (Tue)
by pdundas (guest, #15203)
[Link] (1 responses)
I joke / thou jokest / he joketh, et ceterea...
Posted Jul 20, 2010 17:17 UTC (Tue)
by pdundas (guest, #15203)
[Link]
Posted Jul 6, 2010 23:49 UTC (Tue)
by csamuel (✭ supporter ✭, #2624)
[Link]
Posted Jul 16, 2010 7:48 UTC (Fri)
by dododge (guest, #2870)
[Link]
For further reading they reference Jespersen's "Progress in Language", which discusses it in more detail and gives many more examples. You can find scans of the 1909 2nd edition at books.google.com, with the relevant text in section 24 on pages 27-30.
Posted Jul 6, 2010 11:06 UTC (Tue)
by farnz (subscriber, #17727)
[Link] (4 responses)
Traditionally, in English, you use the plural form as a highly respectful singular. So, for 1st person, you have the "royal we" - or use of 1st person plural for a singular entity. For second person, we've completely lost the 2nd person singular (thou), in favour of always using the 2nd person plural in its role as the respectful 2nd person singular. We also use 3rd person plural as a respectful 3rd person singular in English.
Arguably, the fix to the existing habit of subconsciously sexist language is not to just flip the sexism round some of the time, but to make the same move for 3rd person as we've made for 2nd person - drop he/she/it when referring to a singular entity (except when gender is important), and use the 3rd person plural form ("they are" instead of "he/she/it is") in its traditional role as a respectful singular.
Posted Jul 7, 2010 21:22 UTC (Wed)
by baldridgeec (guest, #55283)
[Link] (3 responses)
Posted Jul 7, 2010 21:26 UTC (Wed)
by farnz (subscriber, #17727)
[Link] (2 responses)
Except that the modern English usage of "one" places it as a variation on the first person, not the third - one tends to use it not to mean "an unidentified individual", but to mean "an individual from the set that I would cover if I were to use we".
Posted Jul 7, 2010 21:51 UTC (Wed)
by baldridgeec (guest, #55283)
[Link] (1 responses)
(Rereading this before submission, I realize that you could just quote the above paragraph and respond with "QED." :) More meat follows below.)
I assume that that sort of observation (that it coincides with an individual from the first person plural set) stems from the fact that one does not often pose arguments which prescribe the behavior of groups which exclude oneself - that doesn't mean it can't happen though.
One may believe that one's computer is powered by hamsters on exercise wheels, but one would be incorrect. :)
Posted Jul 8, 2010 10:20 UTC (Thu)
by farnz (subscriber, #17727)
[Link]
It's a difficult one (the joys of a language defined by usage, not prescribed by an academy); in my experience the use of "one" is either a "posh way of saying I", or "this is what should happen in an ideal world, not necessarily what anyone in particular does". Singular they feels slightly weird, but doesn't come with that baggage.
Of course, this is all based on past experience - and continued use of "one" as a gender-neutral singular would change the implications. If only programming languages had a similar habit of changing to adapt to what is meant, not what it used to mean :)
Posted Jul 6, 2010 10:13 UTC (Tue)
by nye (subscriber, #51576)
[Link]
As a purely factual point, this is incorrect in English.
Posted Jul 6, 2010 11:09 UTC (Tue)
by sorpigal (guest, #36106)
[Link] (3 responses)
Regardless of the reasons for the origin of the use, "he" and "him" are correct when the gender is unknown or ambiguous. Other forms, no matter how common, are not good English.
Posted Jul 6, 2010 11:43 UTC (Tue)
by samth (guest, #1290)
[Link]
Posted Jul 6, 2010 11:49 UTC (Tue)
by nye (subscriber, #51576)
[Link]
Simply wrong. There is no reason to support this assertion; it's a modern invention with no reasoning behind it - simply an arbitrary decision by a handful of grammatical prescriptivists who choose to ignore the large corpus of historical English text, not to mention the overwhelming current usage.
Since we mostly hear it coming from Americans, I conjecture that it may originate in Strunk and White (a highly questionable but ubiquitous American grammar guide).
Posted Jul 6, 2010 13:24 UTC (Tue)
by anselm (subscriber, #2796)
[Link]
Please take this over to the Language Log blog at http://languagelog.ldc.upenn.edu/nll, where linguists, i.e., professionals who know a great deal about things like English grammar and usage, will quickly disabuse you of this notion.
Posted Jul 5, 2010 17:08 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (6 responses)
And this ignores the fact that any interface documentation for a graphics driver's kernel component is likely to be of the form "This ioctl submits a buffer of GPU commands to the device". These commands will typically not be interpreted by the kernel code beyond certain sanity checking, so documenting the interface does little to tell us how to implement a userspace version of the same code. Interface documentation is better than no interface documentation, and hardware documentation is better still. But if we have a kernel component with a well-defined ABI then that impairs our ability to implement a userspace driver unless we also develop a parallel kernel component. And that way lies madness.
Posted Jul 5, 2010 17:35 UTC (Mon)
by avik (guest, #704)
[Link] (5 responses)
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
They have contractual obligations with other vendors to keep some aspects of their hardware secret. This is due to the DRM requirements they have to face.A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
Or better still one could utilize a form which is less oft seen in informal English, but easily remembered by a student of linguistics or esp. Romance languages - the third person indefinite personal pronoun. It exists for precisely this sort of case.
So much grammar correction, so little correct!
So much grammar correction, so little correct!
So much grammar correction, so little correct!
So much grammar correction, so little correct!
s/driver/documentation/
s/driver/documentation/
English
Regardless of the reasons for the origin of the use, "he" and "him" are correct when the gender is unknown or ambiguous. Other forms, no matter how common, are not good English.
This is totally false. First, the use of singular "they" is long-standing and good English, used by "Addison, Austen, Chesterfield, Fielding, Ruskin, Scott, and Shakespeare", to quote the Chicago Manual of Style.
Second, prescriptivism is wrong about language, as a general principle, and thus your second sentence is false regardless of the particular topic.
s/driver/documentation/
s/driver/documentation/
Regardless of the reasons for the origin of the use, "he" and "him" are correct when the gender is unknown or ambiguous. Other forms, no matter how common, are not good English.
s/driver/documentation/
s/driver/documentation/
Once you're at the point of something as complex as a graphics driver, interface documentation is unlikely to be both precise and accurate.
Then the driver+documentation is unlikely to be accepted. We need to insist on quality docs, just as we insist on quality code.
Say we end up with an open kernel driver, a closed userspace implementation and an open userspace implementation. Part of the interface documentation can be interpreted in two different ways, and interpreting it one way gives a significant performance boost to the open component and breaks the closed component. Do we accept the patch or refuse the patch?
We request a clarification to the specification.
What if one interpretation allows DMAing to arbitrary addresses?
Then it's clearly a bug. Both driver and documentation need to be fixed.
None of the above change when you get an open source driver instead of documentation. In fact, a driver is less likely to be complete (since it won't implement all capabilities), though more likely to be accurate (since it can be tested). Documentation contains a superset of the information in a driver, since you can write a driver based on the documentation, but you can't write the entire documentation from reading the driver source.
And this ignores the fact that any interface documentation for a graphics driver's kernel component is likely to be of the form "This ioctl submits a buffer of GPU commands to the device".Such documentation should be rejected. Documentation should describe exactly what happens with the bits, either directly or by referring to hardware documentation.
These commands will typically not be interpreted by the kernel code beyond certain sanity checking, so documenting the interface does little to tell us how to implement a userspace version of the same code. Interface documentation is better than no interface documentation, and hardware documentation is better still.what you describe is not an interface documentation, but a tunnel documentation. That should be rejected.
But if we have a kernel component with a well-defined ABI then that impairs our ability to implement a userspace driver unless we also develop a parallel kernel component. And that way lies madness.Certainly, I got confused just reading that last paragraph.
Posted Jul 5, 2010 17:40 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (4 responses)
Posted Jul 5, 2010 17:50 UTC (Mon)
by avik (guest, #704)
[Link] (3 responses)
s/driver/documentation/
s/driver/documentation/
If we have full hardware documentation and we're expected to write our own userspace, then we also want to write our own kernel code.
Why? If the driver is good, accept it.
There's no incentive whatsoever for us to merge the upstream provided kernel code.
You get not to write that much code.
If we do then we provide an interface that we're expected to support forever (see the argument over nouveau breaking ABI), and the only consumer of that interface is a closed userspace driver.Of course we should encourage an open source userspace driver, and with full documentation, there is really no reason not to open source the driver. But as a rule, adding a syscall should not require adding a consumer for that syscall.
Posted Jul 5, 2010 17:56 UTC (Mon)
by mjg59 (subscriber, #23239)
[Link] (2 responses)
Posted Jul 5, 2010 18:02 UTC (Mon)
by avik (guest, #704)
[Link] (1 responses)
You end up with one driver that can support both the (modified) closed user driver and a newly written open driver.
Posted Jul 5, 2010 20:23 UTC (Mon)
by airlied (subscriber, #9104)
[Link]
Its not something you can assess in abstract form, i.e. until you've written a complete graphics driver, both kernel and userspace components you rarely know if the API you chose is going to be correct and performant. However you generally pick the 80% interface, go with that, and hope you can easily make the 100% interface on top of it later.
However unless a single group is developing the kernel and userspace drivers, generally that API is going to be useless and really constrain any one else. So we end up with a driver in the kernel providing an API that only a closed source userspace can exercise and an API that only a open source userspace can exercise, why should we introduce the first API at all.
I don't mind introducing reduced functionality kernel drivers that don't expose major userspace APIs to just serve as an example of how these GPUs work, I don't want a driver with an API commitment and no way for anyone to make sure the API continue working.
Posted Jul 5, 2010 20:30 UTC (Mon)
by airlied (subscriber, #9104)
[Link]
But merging a driver whose only use is exposing an API for a closed source userspace to use is neither of those things.
The API is the problem, adding a restrictive API that we have to maintain indefinitely with no userspace code to test it is the core of the problem from a maintainer point of view.
Posted Jul 8, 2010 10:07 UTC (Thu)
by willnewton (guest, #68395)
[Link]
It is my understanding that Intel (and their subcontractors) had full documentation of the GMA500 hardware under NDA, but were unable to produce a working driver.
Posted Jul 5, 2010 15:21 UTC (Mon)
by epa (subscriber, #39769)
[Link] (17 responses)
Posted Jul 5, 2010 15:44 UTC (Mon)
by tao (subscriber, #17563)
[Link]
Posted Jul 5, 2010 15:58 UTC (Mon)
by vonbrand (subscriber, #4458)
[Link] (15 responses)
The userspace pieces have to interact with assorted userspace programs, some of which are closed source, thus LGPL at most, preferrably MIT as that is the default license for X.org.
GPLv3 is out, as the kernel won't go GPLv3 in our lifetimes (and the need to exchange pieces with the userspace part is a real possibility); thus GPLv2+ is also out.
Posted Jul 5, 2010 16:16 UTC (Mon)
by mjr (guest, #6979)
[Link]
Posted Jul 5, 2010 16:46 UTC (Mon)
by epa (subscriber, #39769)
[Link] (13 responses)
Posted Jul 5, 2010 17:16 UTC (Mon)
by bronson (subscriber, #4806)
[Link]
Posted Jul 5, 2010 22:54 UTC (Mon)
by airlied (subscriber, #9104)
[Link]
Posted Jul 5, 2010 23:52 UTC (Mon)
by elanthis (guest, #6227)
[Link] (10 responses)
Posted Jul 8, 2010 19:28 UTC (Thu)
by robert_s (subscriber, #42402)
[Link] (8 responses)
Be warned if it's for LWN your ideas will have to be quite well thought out and cogent.
Talking about an "infectious GPL" isn't a good start.
Posted Jul 9, 2010 16:35 UTC (Fri)
by mpr22 (subscriber, #60784)
[Link] (7 responses)
Posted Jul 9, 2010 17:24 UTC (Fri)
by njs (subscriber, #40338)
[Link] (6 responses)
When a library is under the GPL, that's not an infection, it's a price -- you can use the library if you pay it back by freeing your own software in return, or you can not use the library and not pay that price. Totally up to you.
Ironically, some of the people who hate the idea of this kind of quid-pro-quo rant about how it's 'communist'. (And, to drive the point home, also hate the first-sale doctrine, traditional contract law as applied to EULAs, etc.) Really it's 'capitalism' they seem to object to.
Posted Jul 12, 2010 9:03 UTC (Mon)
by mpr22 (subscriber, #60784)
[Link] (5 responses)
Posted Jul 12, 2010 14:10 UTC (Mon)
by njs (subscriber, #40338)
[Link] (4 responses)
But that still has nothing to do with "infections".
Posted Jul 12, 2010 15:40 UTC (Mon)
by bronson (subscriber, #4806)
[Link] (3 responses)
I'm sympathetic to how it could appear like the license is trying to spread on its own. Obviously "infection" is not 100% accurate (what metaphor is?), but I haven't seen a better way to oversimplify this fairly unique aspect of the GPL. I'm afraid "infect" will be used until someone can think of a more appropriate term.
Posted Jul 12, 2010 15:44 UTC (Mon)
by rahulsundaram (subscriber, #21946)
[Link]
Posted Jul 12, 2010 16:11 UTC (Mon)
by nye (subscriber, #51576)
[Link]
Posted Jul 14, 2010 10:55 UTC (Wed)
by mtorni (guest, #3618)
[Link]
I'd like to add two more options to permit a fair comparison:
#3 Relicense (buy) the free library under a license permitting use
Now the fair comparison goes:
With a GPL'd library you have one more choice in this setting.
The comparison becomes more interesting once you consider the options when using libraries in free software or BSD/MIT-licensed software.
It also happens frequently that most benefit would be had by not writing propriertary software at all to tap the most amount of existing free software and interested developers.
Posted Jul 8, 2010 20:29 UTC (Thu)
by vonbrand (subscriber, #4458)
[Link]
Please do write your ideas up!
Posted Jul 5, 2010 16:15 UTC (Mon)
by rbrito (guest, #66188)
[Link] (11 responses)
I would like to put together a new system for my development and one part that I have never understood very well is that related to graphics, particularly in the sense of being able to use it in its full potential.
The situation for desktops is now more comfortable, but it is still not 100% clear for a luser: for instance, its it OK to buy nvidia hardware? The idea that I may be supporting a company that only has its hardware working with reverse-engineered drivers doesn't seem right.
In comparison, AMD/ATI cards seem like they "should have the blessings", but the last time I saw the features that the radeon/radeonhd cards support, it had a good amount TODO items for cards for some time...
http://www.x.org/wiki/RadeonFeature
So, what should one Freedom-conscious user choose in face of the current situation?
Thanks for any comments.
Posted Jul 5, 2010 17:04 UTC (Mon)
by nix (subscriber, #2304)
[Link] (2 responses)
Of the r600/r700 TODOs on that list:
Video decoding using the 3D engine and UVD do not prevent video playback: they only mean that the CPU has to do the video decoding. If you could play back a video on a lesser card, you'll be able to play it back on r600/r700 right now. Shaders are awaiting Gallium. Antialiasing I don't know about; HDMI audio I don't pay attention to as I've got no hardware that cares about it.
Posted Jul 5, 2010 19:11 UTC (Mon)
by svena (guest, #20177)
[Link]
It's also starting to appear for the (Gallium) r300 driver.
Posted Jul 30, 2010 17:22 UTC (Fri)
by moxfyre (guest, #13847)
[Link]
On the other hand, Nvidia has *never* helped with the development of the open-source Nouveau drivers. Those only work because of reverse-engineering.
Intel has been cooperating with and funding open-source graphics driver development for the longest time, so their drivers work well for nearly everything. Intel graphics on my laptop work flawlessly with suspend/HDMI/kernel mode-setting, etc. etc. etc.
So yeah, Intel > ATI > Nvidia in terms of practical features, and Intel ~ ATI >> Nvidia in terms of "vendor doing the right thing these days."
Posted Jul 5, 2010 17:36 UTC (Mon)
by bronson (subscriber, #4806)
[Link] (3 responses)
There are exceptions of course (Intel's GMA500 screwup) but, in general, I try to go with Intel if you value compatibility and stability, and ATI if you want performance and don't mind wrestling with the drivers a bit.
This is the type of wrestling I mean, nothing major: http://bugs.freedesktop.org/show_bug.cgi?id=19943
Posted Jul 5, 2010 18:23 UTC (Mon)
by salimma (subscriber, #34460)
[Link]
My netbook (Intel graphics) can perform 3D effects that puts my laptop (ATi) to shame, and the power drain from the GPU means I barely get 90 minutes of usage out of the standard battery.
Posted Jul 6, 2010 18:38 UTC (Tue)
by rriggs (guest, #11598)
[Link] (1 responses)
I cannot speak for Intel, as their video hardware isn't in the same league as the other two.
With proprietary drivers, nVidia wins hands down for ease of use.
OpenCL (GPGPU) support using open source drivers is non-existent. One must use proprietary drivers. And for this, I prefer ATI.
Posted Jul 8, 2010 1:09 UTC (Thu)
by brouhaha (subscriber, #1698)
[Link]
Posted Jul 7, 2010 9:02 UTC (Wed)
by sdalley (subscriber, #18550)
[Link] (2 responses)
On the X.org wiki RadeonProgram support matrix, Blender3D support is recorded as GOLD for the older Radeon R300 series. Looking at the small print, this means "(Blender) 2.49 requires low impact fallbacks to draw all interface symbols (stipple lines for lamp types, etc), but that affects speed. 2.50 requiries changing triple buffer mode to something else, or unusable (app problem, it seems to happen with other brands and operating systems too)."
The more recent R500 R600 series chipset support is rated as GARBAGE/UNKNOWN. The current R700 is SILVER, which, being translated, means "(26 Oct 2009) [mesa-git] Crashes on many operations and does not update its interface correctly."
For Blender, Radeon is not quite there yet, in other words. Stick with programs marked PLATINUM in the support matrix if you actually need to get stuff done.
Posted Jul 7, 2010 22:12 UTC (Wed)
by svena (guest, #20177)
[Link]
Posted Jul 8, 2010 19:23 UTC (Thu)
by robert_s (subscriber, #42402)
[Link]
Nonsense. I've been using blender on my r200 with the open radeon driver for years without problems.
Posted Jul 8, 2010 19:35 UTC (Thu)
by robert_s (subscriber, #42402)
[Link]
AMD.
The Free drivers work fine for most uses. If you find yourself needing a particular advanced feature, you can use the nonfree driver until the Free one supports it.
Posted Jul 6, 2010 11:49 UTC (Tue)
by nhippi (subscriber, #34640)
[Link] (12 responses)
That is a extremely optimistic version of the Linux graphics story. While open drivers for intel,ati and nvidia exist, the window of RELIABLY working hardware is sometimes incredibly thin. Too old chip (Intel 855GM was really buggy around 2.4..2.9 versions of intel driver) and support is spotty. Too new (GMA500) and no support at all. Nouveau works really well only between NV30<->NV50. I would assume ATI has the same issue of code supporting old HW getting bitrotted and new HW support not being ready yet.
My estimate is that open graphics drivers in Linux would need at least 2-3x the current manpower to keep up with the hardware and kernel infrastructure changes.
Posted Jul 6, 2010 14:35 UTC (Tue)
by Cyberax (✭ supporter ✭, #52523)
[Link] (11 responses)
Wow. That's old.
"Too new (GMA500) and no support at all."
New _Intel_ chips are supported just fine. GMA500 is not Intel chip, it's licensed Poulsbo hardware.
"Nouveau works really well only between NV30<->NV50."
Who cares about earlier chips? And work on the recent Fermi cards is already in progress.
"I would assume ATI has the same issue of code supporting old HW getting bitrotted and new HW support not being ready yet."
ATI even supports kernel modesetting on R200!
Posted Jul 6, 2010 15:45 UTC (Tue)
by nix (subscriber, #2304)
[Link] (9 responses)
Posted Jul 7, 2010 10:03 UTC (Wed)
by nhippi (subscriber, #34640)
[Link] (4 responses)
Like the intel driver supports i855? modulo the bugs that made it completely lock up at random moments in recent versions of the driver (2.10 version appears stable, wont try anything newer now that I have a working setup again).
Then again, I have no ATI display adapter use experience. So it just might be the only video driver that never hangs, shows corrupted textures, has problems resuming from suspend, etc when used with too old or new hardware variants...
The too old/too new issue is also with driver versions.
1. Report a bug on driver X.
I'm not criticizing the driver developers. There is just too few dedicated and active X driver developers compared to the amount of hardware variants that needs supporting and the complexity of graphics driver development...
Posted Jul 7, 2010 18:03 UTC (Wed)
by nix (subscriber, #2304)
[Link]
Posted Jul 8, 2010 16:26 UTC (Thu)
by Thalience (subscriber, #4217)
[Link]
I have an 855-based laptop as well, and the lockups are very frustrating. But it isn't a matter of "driver bugs" so much as "failure to find a good workaround for hardware bugs".
Posted Jul 12, 2010 19:37 UTC (Mon)
by tajyrink (subscriber, #2750)
[Link] (1 responses)
No, no such chip-wide breakage in the ati land. I've r200 working fine, and r100 is reportedly also pretty ok (for the class of hardware it is) under KMS. I've also r700 with the ati driver without a hitch and more stable (that is = stable) than the proprietary driver.
Posted Jul 15, 2010 16:00 UTC (Thu)
by nix (subscriber, #2304)
[Link]
Posted Jul 8, 2010 22:11 UTC (Thu)
by Tet (subscriber, #5433)
[Link] (3 responses)
I must just be unlucky, then. It seems all of my ATI cards are among those with bugs (which yes, have all been reported). I have still yet to find an ATI card with working KMS :-(
Posted Jul 9, 2010 17:15 UTC (Fri)
by nix (subscriber, #2304)
[Link] (2 responses)
(I've got a 4870, FWIW.)
Posted Jul 10, 2010 22:01 UTC (Sat)
by glisse (guest, #44837)
[Link] (1 responses)
Posted Jul 10, 2010 22:50 UTC (Sat)
by Tet (subscriber, #5433)
[Link]
Posted Jul 6, 2010 17:21 UTC (Tue)
by drag (guest, #31333)
[Link]
It's a PowerVR SGX design, by 'Imagination Technologies'. It's the same exact sort of thing that is giving Linux fits on hardware.
Remember the Nokia N800 and N810? Those types of chips were so troublesome that those tablets used no acceleration at all!
http://en.wikipedia.org/wiki/PowerVR
The old Intel 8xx series 'Extreme 3D Blaster' type devices used some PowerVR licensed stuff, I think, but I have no idea how much. The GMA series, up until the GMA 500 and whatever Intel is using in Moorestown, were pure Intel design.
Posted Jul 6, 2010 17:45 UTC (Tue)
by rahvin (guest, #16953)
[Link] (1 responses)
If the following is true, what is the point in ever merging any driver for these devices into mainline? If the driver is a one-off, has to be revised for every revision or version produced there could end up being a LOT of drivers that are all different. Factor out a decade and you could end up with a thousand different drivers for one-off designs that are abandoned/revised 6months-yearly.
I see no point in merging drivers for devices that have no stability, longevity or persistence. At least the Intel/ATI/Nvidia hardware is a consistent design for a period of time with many more sales per design and often a single design with multiple products. Some of these mobile designs could be used in only a few products and end up with little to no market share to where you are dealing with a design used by 0.00001% of the global population. The fear of bit-rot on these drivers is very well founded IMO.
Unless the manufactures can come together and promise to maintain an interface for a period of time where ALL products (or at least >50%) in the class use the same interface there is little purpose in merging IMO.
Posted Jul 8, 2010 8:01 UTC (Thu)
by daniels (subscriber, #16193)
[Link]
There are a number of different versions of the SGX (530 in the N900, 535 shipped by some other vendors, 540 shipped by Intel IIRC), all with slightly different abilities/restrictions, but they mostly behave the same from the driver's point of view. Some of those cores have different revisions to fix hardware issues, but again from the driver's point of view, this is generally just a one or two-liner.
Posted Jul 8, 2010 14:57 UTC (Thu)
by smitty_one_each (subscriber, #28989)
[Link] (1 responses)
Posted Jul 30, 2010 17:25 UTC (Fri)
by moxfyre (guest, #13847)
[Link]
Which Android phones have the best vendor funding and documentation for free software driver development, especially graphics and wireless chipsets?
Having such information available would certainly influence my decision about which handset to buy.
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
s/driver/documentation/
Odd choice of licences
Odd choice of licences
Odd choice of licences
Odd choice of licences
Odd choice of licences
Odd choice of licences
Odd choice of licences
Odd choice of licences
Odd choice of licences
Actually, when the GPL is applied to a library, rather than a program, I'm entirely sympathetic to the viewpoint that describes it as "infectious".
Odd choice of licences
Odd choice of licences
Which is fine until the price becomes "you can't write 3D games on Linux without first reimplementing the graphics driver's userspace library and everything that links against it".
Odd choice of licences
Odd choice of licences
Odd choice of licences
- Clean-room rewrite the library. Huge waste of time.
- Relicense the entire proprietary project under a GPL-compatible license.
Odd choice of licences
Odd choice of licences
Odd choice of licences
#1 Clean-room rewrite the library. Huge waste of time.
#2 Relicense the entire proprietary project under a GPL-compatible license.
#4 Use the library as such
To use an existing non-free library, apply option #1 or #3, #4
To use an existing GPL'd free library, apply option #1, #2 or #3
To use an existing MIT-licensed library, apply option #4 (option #2 and #3 are still recommended, and #1 might come later in the project if needs change)
Odd choice of licences
What graphics card should one buy?
http://www.x.org/wiki/radeonhd%3Afeature
http://www.x.org/wiki/RadeonProgram
What graphics card should one buy?
What graphics card should one buy?
I agree
What graphics card should one buy?
What graphics card should one buy?
What graphics card should one buy?
I think there's little question that the nVidia proprietary drivers are good. I buy ATI rather than nVidia, even though I currently run proprietary drivers, because ATI supports open source while nVidia does not. nVidia is arguably more hostile toward open source than Microsoft.
What graphics card should one buy?
If you need Blender, stick with proprietary nVidia
If you need Blender, stick with proprietary nVidia
If you need Blender, stick with proprietary nVidia
What graphics card should one buy?
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
2. "Thats too old, it might be fixed in the git head"
3. compile, try, hit another issue
4. "you are running it on too old kernel, upgrade to latest kernel from the drm tree"
5. compile, try, hit some other bugs
6. "you are running the developer versions of kernel and graphics driver, of course there are some bugs."
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
> Like the intel driver supports i855?
A line in the sand for graphics drivers
As far as I know, everything that uses the ati driver supports KMS now, modulo bugs
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
A line in the sand for graphics drivers
This may already be available. . .
Is there a URL for a site aggregating sales links to the non-suck vendors? I'm going to be in the market soon.
This may already be available. . .