Editor's Note: The Next Hurdle for Desktop Linux(Mar 9th, 2007, 23:30:54)
(Other stories by Brian Proffitt)
By Brian Proffitt
We just passed a quiet milestone at the beginning of the month. And while the milestone does not seem to affect Linux, it could be mark the beginning of the worst assault on desktop Linux to date.
As of March 1, it seems, all televisions sold in the US are to be HDTV ready.
I know, seems a bit far afield from the joys of Linux, doesn't it? But it could impact Linux, because of what the coming of HDTV represents: the potential marginalization of Linux to older machines or servers.
The reason for this gloomy theory is that for better or worse, the broadcast industry in the US is trudging towards the February 19, 2009 deadline for all television broadcasts to be digital. As the deadline approaches, manufacturers are salivating over the prospect of selling a new TV or digital converter to every household in the nation. With television going to hi-def, HD content will soon be offered on other mediums, too.
In fact, it already has. This week, viewers of the NBC show "Heroes" were treated to a small preview of Spider-Man 3. If you watched the clip, you were told the there would be a much longer HD clip available on the NBC site for the next 24 hours. Right now, HD is still in the cool novelty phase of its existence. Very soon, I think, it will become more expected, and not just by television watchers. HD content will also be in demand by computer users.
Not wanting to miss out on the gravy train, video card manufacturers are already starting to put out digital-ready products, with DCI and HDMI ports. In fact, it will probably become hard to find cards with VGA ports in the near future.
At first, this seemed like this would be just another driver-pain-in-the-butt problem for Linux users. After all, it always seems like we're playing catch-up with hardware vendors, especially since they won't open their driver code. Well, the developers have figured out workarounds before.
The problem is going to be bigger than that. Content providers, ever mindful of their intellectual property, have been demanding DRM protocols be built into the HD cards. Without DRM protection in place, the providers have decided, the HD content will not be viewable at full resolution. This is going to be done through the image constraint token, which according to Cory Doctorow's blog on BoingBoing, "is a flag in a video signal that instructs receivers, DVD players and other high-definition sources to 'down-rez' their output to a low-definition signal when connecting to an 'untrusted' screen or other sink."
Doctorow adds, "The effect is that if your screen or recorder isn't blessed by Hollywood, they can limit the video they send to it to a low-resolution image. Manufacturers who want the full signal have to enter into the HDMI license agreement and agree to cripple their hardware in lots of ways--and have to promise not to make their equipment compatible with anyone else's, unless they, too, agree to cripple their hardware."
In other words, this is going to be a bit more than a driver catch-up problem. If you are a Linux user with one of these cards, unless your software can work with this DRM protection scheme, you won't be able to enjoy the full benefits of HD content. And while I agree that a hack is always possible, it's (a) illegal and (b) video card manufacturers may have to be much more active in preventing unlicenced use of their products in order to stay within the guidelines of any HDMI license agreement in which they enter.
Currently, video card manufacturers are either a little bit helpful with Linux, or they're almost completely passive--they don't care one way or the other if someone hacks a driver to support their cards, since ultimately it makes them a little bit more revenue and they didn't have to do any coding or support.
If HD content will be king, then the manufacturers will have to be far less wishy-washy. They will either have to sign-up for this DRM scheme or they won't. Given that in three or four years, which is when such a DRM plan is expected to be implemented, Vista will have probably gotten itself installed on a majority of the world's desktops and there'll be even more broadband to deliver HD content, only a suicidal card manufacturer would opt out of this DRM scheme.
This will leave Linux on the desktop in a precarious position. Obviously, the base X system won't be affected by this image constraint token, so we'll all still be able to use our GNOME, KDE, Xfce, or whatever desktops and the attendant apps. But what do we tell the potential new Linux user when they want to point Firefox at some HD content on the Web? Or a techie who wants to build his own DVR device? "Sorry, Linux can't do that?"
Does this mean that Linux will be forever behind in the content game? As I menioned before, the solution can (and probably will) be hacked, just as the DeCSS algorithm was cracked so we could watch DVDs on our Linux machines--if we wanted to. Except that DeCSS-hacking applications are still not legal in the US (because God forbid I should watch my DVDs on my Linux machines).
The other choice is to embrace a DRM protocol for Linux. This would give penguin-lovers an OS that would be more likely to be compatible with these DRM-protected cards. But, even as I write that, I realize that such a wish could be as fruitful as spitting at a forest fire. The drafts of the GPL v3 make it clear that DRM will not be a welcome addition to GPL'd software, With GPL 3, Richard Stallman and the Free Software Foundation have drawn a line in the sand regarding DRM.
My question is, looking at the future of digital content, will the GPL 3 forever keep Linux relegated to servers and older machines that don't have HD video requirements?
I submit that this is another hardware challenge facing the Linux community to add to the list of concerns I have addressed here in recent weeks. If anything, this should serve as strong incentive for the community to figure out how to work with hardware vendors, before passive indifference becomes active resistance.
Printed from Linux Today (http://www.linuxtoday.com).