|
|
Subscribe / Log in / New account

Kernel support for HDCP

Kernel support for HDCP

Posted Dec 8, 2017 15:18 UTC (Fri) by JFlorian (guest, #49650)
Parent article: Kernel support for HDCP

I am no fan of DRM, quite the opposite in fact, but it seems incongruous to reject an attempt to bring something like this into the mainline. There's no end of preaching about how much better it would be if some proprietary driver were simply mainlined. Shouldn't Linux be more welcoming?


to post comments

Kernel support for HDCP

Posted Dec 8, 2017 17:20 UTC (Fri) by mageta (subscriber, #89696) [Link] (1 responses)

I doubt even a single company will consider bringing more drivers into the kernel, just because some DRM was accepted. Maybe more DRM drivers, at best.

Showing "goodwill" here buys us nothing.

But I guess its the practical thing to do...

Kernel support for HDCP

Posted Dec 8, 2017 19:29 UTC (Fri) by JFlorian (guest, #49650) [Link]

I completely agree. My comment was intended to point out the double standard.

Kernel support for HDCP

Posted Dec 9, 2017 6:24 UTC (Sat) by flussence (guest, #85566) [Link] (2 responses)

I don't see it as any different than the wireless regulatory code. That's been mainline for years now, and all that changed is corporate imbeciles like Broadcom/Qualcomm lost their main excuse to hide everything behind proprietary firmware, and indeed they eventually caved and we no longer need b43-fwcutter or ndiswrapper. Not that the vendor-written mainline drivers are much better…

Now the same spotlight will be shining on AMD and nVidia, who've both just lost the #1 excuse for, respectively, gerrymandering radeonhd/avivo to death and being nVidia. If they won't shape up, the hacker subculture that's currently tearing Intel ME to shreds will probably answer for them without the mercy of an NDA. Who knows what skeletons are in their blob firmware closets?

Kernel support for HDCP

Posted Dec 10, 2017 0:54 UTC (Sun) by pabs (subscriber, #43278) [Link] (1 responses)

When did Broadcom/Qualcomm release their WiFi firmware source code under a FLOSS license?

The only WiFi vendor I know of who did that was Atheros before they were bought by Qualcomm (ar9170.fw and open-ath9k-htc-firmware). The Free Software advocate who was responsible for that left the company before the sale IIRC, so it seems unlikely Qualcomm would start releasing code.

The WiFi firmware reverse engineering efforts I'm aware of are not doing very well. The last OpenFWWF release was one year ago. p54u is completely dead and the source code seems gone from the Internet.

Kernel support for HDCP

Posted Dec 15, 2017 8:27 UTC (Fri) by flussence (guest, #85566) [Link]

>When did Broadcom/Qualcomm release their WiFi firmware source code under a FLOSS license?
They didn't, but for a long time they clung to regulatory laws as an excuse for having proprietary *drivers* too - that's the whole charade CRDA was built to shoot down, and it was mostly successful. We no longer need b43-fwcutter because there's no driver blob to cut the firmware out of.

My point is that by having HDCP in-kernel, there's another nail in the coffin for proprietary graphics driver blobs (Broadcom/Qualcomm are awful in this area too). Closed firmware is still Evilâ„¢ but it's usually tiny compared to drivers, thus much easier to figure out what's being kept hidden and put targeted pressure on the vendors.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds