A line in the sand for graphics drivers

Posted Jul 5, 2010 13:52 UTC (Mon) by Baylink (guest, #755)
Parent article: A line in the sand for graphics drivers

I posted this to Dave's LJ, but I'll ask here, as well:

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...?

A line in the sand for graphics drivers

Posted Jul 5, 2010 14:35 UTC (Mon) by tzafrir (subscriber, #11501) [Link] (9 responses)

So Intel and ATI ones just happen not to have any trade secrets?

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?

A line in the sand for graphics drivers

Posted Jul 5, 2010 14:39 UTC (Mon) by Baylink (guest, #755) [Link] (4 responses)

As I thought I'd noted: it might reveal that the vendor who won't open the drives is themselves violating *someone else's patent*.

A line in the sand for graphics drivers

Posted Jul 9, 2010 9:57 UTC (Fri) by yoe (guest, #25743) [Link] (3 responses)

Everyone who writes some software is violating everyone else's patent. That's not an issue.

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.

A line in the sand for graphics drivers

Posted Jul 9, 2010 10:21 UTC (Fri) by __alex (guest, #38036) [Link] (1 responses)

It does make it much easier for patent trolls to spam vendors with litigation if they can simply grep through some source files for bits of code that look vaguely infringing though right? I have no idea if vendors actually think this way but I can see where this argument comes from.

A line in the sand for graphics drivers

Posted Dec 27, 2010 15:11 UTC (Mon) by ksandstr (guest, #60862) [Link]

Program code cannot be analyzed for patent violations by simply grepping through it.

A line in the sand for graphics drivers

Posted Jul 9, 2010 17:14 UTC (Fri) by njs (subscriber, #40338) [Link]

Whether you knew about the patent only affects how much the patent owner can demand in damages -- they can in any case stop you from shipping your product and demand a chunk of all your past revenue.

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.

A line in the sand for graphics drivers

Posted Jul 5, 2010 14:52 UTC (Mon) by ernstp (guest, #13694) [Link] (3 responses)

Intel and ATI have written new implementations from scratch in the open, not open sourced existing code. That's where the big problem lies I think...

A line in the sand for graphics drivers

Posted Jul 5, 2010 15:36 UTC (Mon) by drag (guest, #31333) [Link] (2 responses)

It's a combination of different issues.

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.

A line in the sand for graphics drivers

Posted Jul 5, 2010 16:14 UTC (Mon) by smurf (subscriber, #17840) [Link] (1 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.

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.

A line in the sand for graphics drivers

Posted Jul 5, 2010 16:20 UTC (Mon) by drag (guest, #31333) [Link]

> Hardware coupling is obviously not a problem in a smartphone (unlike HDMI).

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.

A line in the sand for graphics drivers

Posted Jul 5, 2010 21:03 UTC (Mon) by airlied (subscriber, #9104) [Link]

For x86 drivers there is a lot of things they consider secret and they share a driver between Windows and Linux. But as I said in the original post, embedded is a different field, they don't have a Windows driver, since nobody really cares about it, it the secondary platform in this space.

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.