Status updates for three graphics drivers
Drivers for graphics hardware are an important part of the graphics stack, so it was not unexpected that the 2015 X.Org Developers Conference had several status updates for free graphics drivers. Three projects had talks: the Nouveau driver for NVIDIA devices, the amdgpu driver for AMD hardware, and the Etnaviv driver for Vivante GPUs. Each presented an update on its progress and plans. Something of a summary for each presentation follows; those interested in more detail can consult the program page for links to the slides and videos from each of the talks.
Nouveau
Alexandre Courbot of NVIDIA and Martin Peres of Intel started their talk by clarifying the role their companies play in the project. For Peres, the Nouveau work is strictly done in his spare time and has no connection to Intel at all. Courbot is paid by NVIDIA to work on Nouveau, but that work is mostly focused on supporting Tegra devices, so NVIDIA has "not taken over Nouveau development", he said.
They noted that the last status update was at FOSDEM in 2014 (more than a year and a half earlier) and that there have been many improvements since then. A big refactoring of the kernel driver core architecture that had been started back in the Linux 3.7 days was completed. The effort was led by Ben Skeggs and will be finished as of the upcoming Linux 4.3 kernel.
In addition, support for the NVIDIA virtualization interface has been added. The goal is to allow GPU virtualization with low performance impact. Samuel Pitoiset has added support for performance counters to the driver (which was the subject of another talk). Reclocking support, which allows for different performance levels of the hardware, has been added for more GPUs. That has mostly been for Kepler GPUs, but Maxwell reclocking had been added that morning, Peres said.
There are some proposals from NVIDIA that have been merged or are in progress. Explicit handling of coherent objects between the CPU and GPU has been added to the driver. Objects can be marked so that the driver will keep them cache-coherent between the two processors even on buses that are not guaranteed to be coherent. There is a new submit ioctl() that allows user space to handle synchronization, which is not yet merged but would bring performance improvements, Courbot said.
Peres noted that NVIDIA releases a lot of graphics cards, which makes it hard to keep up on the user-space (Mesa) side. Maxwell support was added to Mesa back in mid-2014. Beyond that, support for OpenGL 3.3 for NVIDIA hardware came in Mesa 10.1, and OpenGL 4.1 support came in Mesa 11. Upcoming work includes more graphics-related performance counter support, including an API to expose the counters to other programs.
On the device-dependent X (DDX) side of things, xf86-video-nouveau has dropped support for the Glamor 2D driver. Those who want that support should use the xf86-video-modesetting driver instead.
Courbot said that support for the Tegra K1 (GK20A) was released in January 2014. That code came from NVIDIA and surprised many people at the time. By October 2014, there was "out of the box" Mesa support for the hardware and the patches for the kernel driver are now upstream. Basic kernel support for the Tegra X1 (GM20B) was merged for 4.3 and more features are planned.
Applications that use kernel mode setting (KMS), such as Weston and X, assume that the display components (which send graphical data to the screen) and render components (which produce off-screen data from the graphics commands) are the same device. That is generally true for discrete GPUs (dGPUs), but is not true for mobile devices like Tegra. That means that there is still work to do before applications will display properly on those devices. Courbot suggested that render nodes, which were added a few years back, should be used, though that doesn't completely solve the problems.
First-generation Maxwell GPUs (GM107) were supported initially back in March 2014 using NVIDIA's firmware. By April 2015, open-source firmware had been released and was supported by the driver. But support for the second generation (GM204+) has been stalled for all of 2015, waiting for the release of signed firmware by NVIDIA. Those GPUs will not load firmware unless it is signed with an NVIDIA key.
The problem is wider than just Maxwell, as newer Tegra GPUs also have this requirement. Courbot said that NVIDIA will be releasing signed firmware but that it hasn't happened yet. The code to load signed firmware is mostly working at this point, but there is an internal workflow issue at NVIDIA that needs to be resolved in order to release the firmware. It is normally linked into the binary driver, but there needs to be a separate release of the firmware for Nouveau.
There has been a lot more cooperation between NVIDIA and Nouveau over the last few years. Beyond official support for Tegra GPUs, there is ongoing work to provide generated header files with proper register names and descriptions from the NVIDIA documentation. In addition, there is some open documentation [FTP] available, though it is "still pretty scarce", Courbot said. There is a (non-public) mailing list where Nouveau developers can ask questions and get answers, which sometimes results in additional documentation being written and released. There is still room for improvement, but the relationship between NVIDIA and Nouveau has gotten better and better over the years.
amdgpu
Alex Deucher and Jammy Zhou from AMD gave an overview of the status of the amdgpu project, which is meant to unify AMD's Linux driver offerings. The driver is taking advantage of the existing open-source infrastructure, such as the TTM memory manager, direct rendering manager (DRM) subsystem, Glamor, and so on.
The amdgpu driver is based on the current upstream Radeon driver. There will effectively be two versions of the driver, one that is all open source and a "pro" version that contains some closed-source components. The closed components are an OpenGL user-mode driver (UMD) and two pieces that will eventually become open source: OpenCL and Vulkan support. There is already Gallium3D-based OpenCL support for the open-source driver.
The amdgpu driver has ioctl() interfaces based on those in the Radeon driver for command submission and memory management. It uses the common mode-setting ioctl() interface. There is a libdrm_amdgpu library that provides a common interface for both the open and closed versions of the driver. The FirePro add-on, which adds "workstation class" features, will be open source (though it may not be accepted upstream) and will only be used by the driver if "absolutely necessary". There is a Mesa user-space driver for OpenGL support.
The initial driver was merged into Linux 4.2, supporting Volcanic Islands GPUs and with experimental support for Sea Islands hardware. Support for Fiji GPUs was added in Linux 4.3. Initial OpenGL support for Volcanic Islands hardware was merged for Mesa 11.0. In addition, initial support for libdrm_amdgpu was merged into libdrm 2.4.63.
Plans for the future include enabling the software GPU scheduler by default, adding a new display component, and adding a new power component called PowerPlay. Support for more graphics hardware is also planned. Both the currently closed OpenCL and Vulkan components will be turned into open-source projects that will be run by AMD. They will share their code bases with the closed-source versions for other operating systems, so they will likely remain as standalone projects.
Etnaviv
Lucas Stach, a kernel and graphics developer at Pengutronix, presented on the Etnaviv project, which supports the Vivante IP core used by multiple different systems-on-chip (SoCs). There are several hardware vendors that are using the Vivante core, but probably the most interesting are Marvell and Freescale, both of which have multiple SoC lines using those GPUs.
The project started as a reverse-engineering effort by Wladimir J. van der Laan with contributions from Christian Gmeiner and others. A lot of the commands and the instruction set are known at this point, so Stach did not have to do any reverse engineering of his own.
Vivante hardware has separate cores for 2D, 3D, and vector graphics, which can be combined in various ways on a particular SoC. The 3D core is straightforward; it is modeled after the DirectX 9 pipeline with the addition of unified shaders. Newer and bigger models of the hardware add the ability to run programs using the OpenCL embedded profile.
The different ways that the cores can be arranged makes a difference in how the kernel driver is implemented. One configuration would have a single fetch engine (FE), which is just a "fancy DMA engine", that feeds all three cores. That single FE is exposed to user space as a single channel for rendering.
Another configuration has three FEs, one per core, so 3D acceleration could be handled in parallel with 2D or vector graphics rendering. Each FE is exposed as a separate channel, but that makes synchronization trickier. There may also be multiple "pixel pipes"—the component that runs shader programs and writes out the data. That allows for parallelism and better performance in rendering; it is somewhat akin to the scalable link interface multi-GPU support from NVIDIA. Stach has never seen hardware that has that capability, but the obfuscated GPL driver that Vivante has released supports it.
There are a number of reasons to want a FOSS driver for Vivante GPUs beyond the obvious "FOSS drivers are awesome" reason, Stach said. Integrating vendor drivers is a serious pain point for his customers (and others). The obfuscated kernel driver is huge and only works with Linux 3.14; it also requires closed-source user-space libraries. No security audit is possible for the code and fixes do not necessarily come in a timely fashion.
For these reasons, his customers demand open drivers where they can fix bugs on their own. The Freescale i.MX6, for example, is used in a lot of automotive and industrial applications. It has a fifteen-year guaranteed availability, so the last newly-built devices using the chip may ship in 2027, as it was introduced in 2012. Running the vendor driver may well be impossible by then.
The kernel driver work was started by Gmeiner in 2014 as a clone of the freedreno driver adapted to the Vivante hardware. Stach cleaned it up and sent it out as an RFC in April 2015. That received some comments that have been addressed and it is now out for additional comments.
Since the first version, the user-space API has been significantly reworked to avoid a problem where the command stream could be changed after the driver had validated it. The cache handling for non-cache-coherent architectures has been fixed. GPU suspend and resume are now working and there have been lots of stability improvements. Etnaviv can now replace the "fat and obfuscated" Vivante kernel driver with one that has readable code and is much smaller—instead of 60,000 lines of code, Etnaviv is around 6,500.
There is still work to be done on the kernel side, including using the dynamic voltage and frequency scaling (DVFS) available in the cores. The command-stream validation needs to be improved and support for per-client MMU contexts needs to be added; both have security implications. If support for the MMUv2 interface on some hardware can be added, it would remove the need for the command-stream validation on those platforms. Exposing the performance counters to user space is needed as well.
Russell King has gotten the xf86-video-armada driver working using libetnaviv on top of the Vivante kernel driver. That uses the 2D GPU and provides acceleration for some common operations. Gmeiner started a libdrm for Etnaviv (etna-drm) as another freedreno clone. It has been updated for the new user-space API and some cleanups have been done, so it is ready for review. There is also a Mesa driver that is able to run simple applications—including Quake 3.
As can be seen, there has been quite a bit of progress in the world of free drivers. It is not all that long ago that open-source graphics drivers were essentially non-existent, but that has changed substantially—and that process appears to be accelerating. Some surprising vendors are participating and even the world of mobile graphics is seeing major progress these days. It is all rather heartening to see.
[I would like to thank the X.Org Foundation for travel assistance to
Toronto for XDC.]
| Index entries for this article | |
|---|---|
| Conference | X.Org Developers Conference/2015 |
Posted Oct 7, 2015 18:01 UTC (Wed)
by flussence (guest, #85566)
[Link] (1 responses)
Posted Oct 7, 2015 21:11 UTC (Wed)
by drag (guest, #31333)
[Link]
It seemed to me like usable R300 drivers didn't show up until well after you could no longer buy that hardware new.
Posted Oct 7, 2015 18:19 UTC (Wed)
by tau (subscriber, #79651)
[Link] (26 responses)
Posted Oct 7, 2015 19:47 UTC (Wed)
by alvieboy (guest, #51617)
[Link] (6 responses)
Care to share pointers to where you believe that obfuscation exists ? Just wanted to see if you have a point (or not).
Alvie
Posted Oct 7, 2015 20:07 UTC (Wed)
by ballombe (subscriber, #9523)
[Link]
> Stach has never seen hardware that has that capability, but the obfuscated GPL driver that Vivante has released supports it.
Posted Oct 9, 2015 2:49 UTC (Fri)
by xobs (guest, #104247)
[Link] (4 responses)
/* Append LOAD_STATE. */
Posted Oct 9, 2015 14:39 UTC (Fri)
by bcopeland (subscriber, #51750)
[Link] (2 responses)
buffer[0] = (1 << 31) | ((count & 0x3ff) << 16) | (address & 0xffff);
(Just to satisfy my own curiosity, based on my looking at objdump -S output and no other context, mistakes are my own, etc.)
Posted Oct 9, 2015 14:45 UTC (Fri)
by bcopeland (subscriber, #51750)
[Link] (1 responses)
Posted Oct 15, 2015 20:19 UTC (Thu)
by pizza (subscriber, #46)
[Link]
(I've seen a lot of this sort of thing, unfortunately...)
Posted Oct 12, 2015 12:56 UTC (Mon)
by cortana (subscriber, #24596)
[Link]
Posted Oct 15, 2015 11:22 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (18 responses)
Any source release will be done either (a) by the copyright holder, or (b) with their consent and permission.
If I understand you correctly, the SFC will therefore not want to touch this case with a bargepole - at best they'll be heartily laughed out of court, and at worst counsel could be fined or jailed for wasting the court's time.
BIG LEGAL HINT - Copyright licenses don't apply to copyright holders!!! If the copyright holder chooses to release double-dutch source under the GPL, then then for you, one you can't complain to anyone that all you have is double dutch, and two, for you double dutch IS the preferred form for modification, because it is the ONLY form you are entitled to have!
Cheers,
Posted Oct 15, 2015 15:44 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link] (17 responses)
Posted Oct 15, 2015 16:16 UTC (Thu)
by andresfreund (subscriber, #69562)
[Link] (15 responses)
Posted Oct 16, 2015 2:05 UTC (Fri)
by nybble41 (subscriber, #55106)
[Link] (14 responses)
Yes, the copyright holders for the Linux kernel get to decide what the preferred form of modification is for code included in derivative works of the Linux kernel.
(Or did you mean something else, like each contributor getting to decide what the preferred form is for their own small part, which would render the clause completely useless?)
Posted Oct 19, 2015 15:00 UTC (Mon)
by Wol (subscriber, #4433)
[Link] (13 responses)
Actually, that is the only interpretation that is possible. And no it doesn't render the clause useless.
If the other copyright holders consider that "the preferred form" is unsuitable, they simply don't pull it into their tree. What they can NOT do is tell someone else what that someone else is allowed to do with their own code.
Cheers,
Posted Oct 19, 2015 15:53 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link] (12 responses)
Their tree isn't the only one that matters when you consider derivative works. One cannot take GPL code from party A plus (nominally) GPL code from party B, which party A considers obfuscated and not "the preferred form for modification", and distribute a derivative work including code from both sources. That is the entire point, really, of the clause requiring that the modified code be distributed in the "preferred form". Otherwise I could trivially circumvent the GPL by combining other people's GPL'd code with my own obfuscated modifications (a hex dump of the binary, perhaps) and call that the "preferred form".
Either the "preferred form" is defined objectively with reference to some external community standard, or all the copyright holders in the combined work need to agree that the code is in the "preferred form". Nothing else makes sense.
Posted Oct 19, 2015 16:19 UTC (Mon)
by sfeam (subscriber, #2841)
[Link] (11 responses)
Posted Oct 19, 2015 17:34 UTC (Mon)
by nybble41 (subscriber, #55106)
[Link] (10 responses)
Posted Oct 19, 2015 20:41 UTC (Mon)
by madscientist (subscriber, #16861)
[Link] (9 responses)
Posted Oct 20, 2015 17:33 UTC (Tue)
by nybble41 (subscriber, #55106)
[Link] (8 responses)
The really interesting case is when a copyright holder releases obfuscated code under the GPL. They have the right to do that, provided it isn't a derivative work—it's their code, they can release it however they want. The license is for the benefit of the recipients. Can someone else without access to the original, unobfuscated code combine what they received with third-party GPL code? It's the only form of the code they have, so it must be *their* "preferred form for modification" even if the original code looked entirely different.
Posted Oct 21, 2015 13:26 UTC (Wed)
by Wol (subscriber, #4433)
[Link] (7 responses)
You (a licensee) have no right to tell me (the copyright holder) what is the "preferred form".
The only sanction you have available is to refuse to use my code. Which is a freedom that the FSF would uphold :-)
It still amazes me that if someone makes a gift of code, the recipients of said gift seem to take it as their god-given right to carp and moan about the giver's bad behaviour ...
Cheers,
Posted Oct 21, 2015 15:41 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (6 responses)
If the driver can't be distributed along with the kernel, it's essentially useless. The only way for one to use it would be to download the driver source and compile it for one's own system, which most users won't do.
Posted Oct 21, 2015 17:39 UTC (Wed)
by sfeam (subscriber, #2841)
[Link] (5 responses)
Posted Oct 21, 2015 19:57 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (4 responses)
Yes, exactly. This is obviously the case where one of the authors is the one trying to combine the works; otherwise the "preferred form for modification" clause would be meaningless. While you can release whatever you want under the terms of the GPL, it can't be enough to simply claim that the (obfuscated) code you're adding to another GPL project is in the proper form, when the other contributors disagree.
The only question is whether you can circumvent the clause less directly by releasing obfuscated code with a GPL license but not combining it with the other project yourself, leaving that up to third parties who need to distribute the combined work.
Posted Oct 21, 2015 20:25 UTC (Wed)
by sfeam (subscriber, #2841)
[Link] (3 responses)
So according to that theory, the author of the work has fewer rights with respect to combining it than 3rd party recipients have? IANAL and all that, but I find that conclusion hard to swallow.
It would be strange to reject a contribution from the original author while saying the same bit of code with the same controlling license would be acceptable if passed through a 3rd party.
You lost me at the point where somehow "other contributors" get to decide what GPL works can be combined. So far as I know, that level of control was ceded by releasing the contribution as a GPL work in the first place. After that they no longer have control over how it is combined with other GPL works. If they didn't want their work incorporated into other GPL projects then they should have released it under a different license. Of course if those same "other contributors" are also managing the project then yes, they will be able to reject the new contribution if it is not to their taste. But that power comes from their position as project manager, not from their status as copyright holder on a previous piece of GPL code.
Posted Oct 21, 2015 22:55 UTC (Wed)
by nybble41 (subscriber, #55106)
[Link] (2 responses)
That would not be my argument. It seems to be what Wol is suggesting. I would argue that neither the original author nor 3rd party recipients have the right to combine obfuscated code (even if provided under a GPL license from the author) with other GPL code where the obfuscated version is not deemed by the other contributors to be in the "preferred form for modification".
> You lost me at the point where somehow "other contributors" get to decide what GPL works can be combined. So far as I know, that level of control was ceded by releasing the contribution as a GPL work in the first place. After that they no longer have control over how it is combined with other GPL works.
There are requirements about how GPL projects can be modified beyond simply that the modifications must also be released under the GPL. One of those requirements is that the source code of your altered version must be provided to others in the "preferred form for modification". Whether you consider that form to be determined by the previous contributors, the FSF, or "community standards", it clearly can't be left entirely up to the author of the modifications.
As I said before, the clause is really much to vague, but all the same it's a critical part of ensuring that the source code the GPL requires is actually usable code, and not obfuscated to the point that it provides nothing beyond what you could get by disassembling the binary.
Posted Oct 22, 2015 0:45 UTC (Thu)
by smckay (guest, #103253)
[Link] (1 responses)
Posted Oct 22, 2015 17:32 UTC (Thu)
by nybble41 (subscriber, #55106)
[Link]
I agree. That doesn't prevent the Vivante driver code from being released under a GPL license, so long as the work isn't considered derivative; copyright holders are not bound by the terms of the licenses they grant to others. Which leads to the question that I've been asking: could someone take the GPL-licensed (but obfuscated) Vivante driver, build a binary which is a derivative work of both the Vivante driver and the Linux kernel, and distribute that binary without violating the GPL license of the kernel?
Posted Oct 16, 2015 1:06 UTC (Fri)
by cortana (subscriber, #24596)
[Link]
Posted Oct 7, 2015 21:58 UTC (Wed)
by luto (guest, #39314)
[Link] (3 responses)
Posted Oct 7, 2015 23:03 UTC (Wed)
by mmechri (subscriber, #95694)
[Link]
Posted Oct 7, 2015 23:31 UTC (Wed)
by jake (editor, #205)
[Link]
Hmm, I thought I had a Wikipedia link in for that, but I see I misplaced it (or misremembered it). In any case, I just put one in there ... not sure it helps immensely, but it should help some ...
jake
Posted Oct 8, 2015 3:57 UTC (Thu)
by liam (guest, #84133)
[Link]
Posted Oct 9, 2015 7:39 UTC (Fri)
by intgr (subscriber, #39733)
[Link] (2 responses)
I was under the impression that Glamor is the future, to replace older compositing interfaces with one based on OpenGL? And that XWayland requires Glamor? So why are they dropping it?
But it's more than likely that I'm misunderstanding things.
Posted Oct 9, 2015 9:36 UTC (Fri)
by mjg59 (subscriber, #23239)
[Link] (1 responses)
Posted Oct 12, 2015 9:17 UTC (Mon)
by kugel (subscriber, #70540)
[Link]
Posted Oct 13, 2015 15:48 UTC (Tue)
by jhoblitt (subscriber, #77733)
[Link] (4 responses)
Posted Oct 15, 2015 9:33 UTC (Thu)
by ssokolow (guest, #94568)
[Link] (3 responses)
Make the thing lie about being a better card than it really is, cheat the buyer, and let nVidia take the blame for the poor performance.
Posted Oct 15, 2015 11:25 UTC (Thu)
by Wol (subscriber, #4433)
[Link] (1 responses)
NCR circa 1900 for example, and I gather it's feared a recent Supreme Court Of The US ruling on free speech may be on the verge of bringing those days back ,,,
Cheers,
Posted Oct 15, 2015 12:03 UTC (Thu)
by ssokolow (guest, #94568)
[Link]
I'm just sharing their excuse.
Posted Oct 18, 2015 16:38 UTC (Sun)
by flussence (guest, #85566)
[Link]
It's much more profitable to have one production line and product-bin it purely in software to meet quotas than to actually QA the hardware and sell it for what it physically can do. Those profits don't last very long when firmware modders can outsmart the firmware authors - which was a regular occurrence until now.
Status updates for three graphics drivers
Status updates for three graphics drivers
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
buffer[0]
= ((((gctUINT32) (0)) & ~(((gctUINT32) (((gctUINT32) ((((1 ? 31:27) - (0 ? 31:27) + 1) == 32) ? ~0 : (~(~0 << ((1 ? 31:27) - (0 ? 31:27) + 1))))))) << (0 ? 31:27))) | (((gctUINT32) (0x01 & ((gctUINT32) ((((1 ? 31:27) - (0 ? 31:27) + 1) == 32) ? ~0 : (~(~0 << ((1 ? 31:27) - (0 ? 31:27) + 1))))))) << (0 ? 31:27)))
| ((((gctUINT32) (0)) & ~(((gctUINT32) (((gctUINT32) ((((1 ? 25:16) - (0 ? 25:16) + 1) == 32) ? ~0 : (~(~0 << ((1 ? 25:16) - (0 ? 25:16) + 1))))))) << (0 ? 25:16))) | (((gctUINT32) ((gctUINT32) (Count) & ((gctUINT32) ((((1 ? 25:16) - (0 ? 25:16) + 1) == 32) ? ~0 : (~(~0 << ((1 ? 25:16) - (0 ? 25:16) + 1))))))) << (0 ? 25:16)))
| ((((gctUINT32) (0)) & ~(((gctUINT32) (((gctUINT32) ((((1 ? 15:0) - (0 ? 15:0) + 1) == 32) ? ~0 : (~(~0 << ((1 ? 15:0) - (0 ? 15:0) + 1))))))) << (0 ? 15:0))) | (((gctUINT32) ((gctUINT32) (Address) & ((gctUINT32) ((((1 ? 15:0) - (0 ? 15:0) + 1) == 32) ? ~0 : (~(~0 << ((1 ? 15:0) - (0 ? 15:0) + 1))))))) << (0 ? 15:0)));
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Wol
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Wol
Obfuscated "GPL" driver?
Reference to some external community standard or consensus would not work either. If that were the whole of it, then a change in community preference could invalidate the license status of code going back decades.
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
I always assumed it meant the form that the copyright holder preferred to use when they modified the code themselves. It should not be difficult, from a legal perspective, to show whether or not the copyright holder really uses the same form of the code when they modify it internally, compared to the form in which they distribute it. If they really edit the obfuscated code directly and don't have the un-obfuscated code around to make changes then convert it again, well, then, it sucks to be us but it's not violating the license. I'm not sure I see the big hole in this.
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Wol
Obfuscated "GPL" driver?
Are you implying that a disagreement between the original authors of one piece of GPL code and the authors of another piece of GPL code can prevent combination of the two GPL works?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
> Yes, exactly. This is obviously the case where one of the authors is the one trying to combine the works.
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Obfuscated "GPL" driver?
Status updates for three graphics drivers
Status updates for three graphics drivers
Status updates for three graphics drivers
Status updates for three graphics drivers
Status updates for three graphics drivers
Status updates for three graphics drivers
Status updates for three graphics drivers
Status updates for three graphics drivers
Status updates for three graphics drivers
Status updates for three graphics drivers
Wol
Status updates for three graphics drivers
Status updates for three graphics drivers