Live data from Hacker News

HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

arstechnica.com

161–170 of 170 posts

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#161

Earlier quoted context omitted.

It’s niche I’ll admit, but a while back the lack of support for DisplayPort in home theater equipment bit me because I had an Oculus Rift (original) hooked up to the same machine, using the only HDMI output on the computer’s GPU which meant hooking it up to the TV (through a receiver) required a DisplayPort → HDMI adapter. Thing is, DP → HDMI adapters all suck when you’re using them to send anything but a basic 1080p…

It's complicated, but the tldr is: use a DP++ type 2 adapter that advertises 4k compat. DP++ adapters tell the GPU to output an HDMI signal instead (DP is an entirely different protocol), and then just level-shift the signal. Type 1 adapters are limited to i-forgot-how-many MHz which means no more than 1080p60. Type 2 adapters contain a tiny 256 byte rom that tells the GPU its maximum supported bandwidth. Other adapt…

I haven't noticed any perceptible latency from any active DP → HDMI I've used, and I'd honestly be surprised to see any inexpensive active DP → HDMI adapter introducing latency, if only because doing so would require a frame buffer, which drives up costs.

What I have seen is DP → HDMI adapters that only support chroma subsampled pixel formats at 4kp60, and TVs that introduce many frame times' worth of latency due to various post-processing effects.

My hunch is as follows: given that consumer video devices (DVD/Blu-ray, set top box) almost exclusively output chroma-subsampled 4:2:2/4:2:0 YCbCr formats, TV post-processing pipelines may only support these formats, causing RGB (and possibly 4:4:4 YCbCr) signals to bypass post-processing, similar to the "PC" or "Game" modes present on some TVs that do the same.

In other words, if adapter → 4:2:2/4:2:0 and 4:2:2/4:2:0 → TV post-processing → latency, then adapter → latency, even if the adapter itself introduces no significant latency.

If I'm correct, the solution is an adapter which supports RGB output at the desired resolutions and frame rates and/or a TV with a PC/Game mode that bypasses post-processing for all source types, both of which are highly desirable for "monitor" use in any case.

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#162

Earlier quoted context omitted.

Except that most laptops today have only DP, and basically all USB-C=>HDMI adapters are USB-C => DP alt mode => HDMI adapters. And outside of gaming consoles it is becoming increasingly more rare to connect anything to the TV outside of the luxury segment (as even build in sound often is better then any external sound up to a price region where the lower luxury segment starts, so buying a slightly better TV without a…

Generally agree, except for the sound part. TV speakers are awful. No matter the TV you should always have an external system.

I thought so too until I bought a TV ~1.5years ago and regretted having bought a sound system as it added hardly any benefit (and it wasn't a cheap or low quality sound system either).

Through I do not have the space to have any speakers behind the couch so it's only 3.1 either way.

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#163
FWIU HDMI leaks signal whereas DP DisplayPort is designed to reduce emanations, anyway. https://news.ycombinator.com/item?id=36681814#36685387

Almost anti-competitive that the HDMI 2.1 spec people won't allow an open implementation.

That they don't even allow open implementation should have been a red flag to all of us that HDMI 2.1 has not been subjected to sufficient review.

Have any of you sufficiently reviewed an actual implementation of this spec? Only with black-box testing because it's closed source?

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#164
post #147

Earlier quoted context omitted.

Sure. Try dumping SkyShowTime shows/movies then. (refuses to run on GNU/Linux). The average power user won't be able to run SkyShowTime on Linux. The idea is locking everyone on Windows, OS X or Linux with Secure Boot and verifiable boot chain if you want to watch movies or TV shows.

Crackers will just use kvm for virtualisation and dump whatever they want either directly or over SPICE.

Probably. Though I'm still wondering why hasn't Microsoft implemented some kind of roles along Verified Boot.

No-one, in Hollywood's view, should be able to watch protected content on a VM. Plus for me it's choppy. Waiting for better virtio graphics drivers for Windows (bugs exist in Visual Studio with HW accel on and there is no 3D support).

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#166
post #119

Earlier quoted context omitted.

Legal aspects of something that can never happen? Why? Try legal aspects of reverse engineering a binary driver. That's more realistic.

It's hypothetical. There is no difference between those two scenarios, we could also just assume the hacker pulled it out of their ass...

Fine, but it's useless then.

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#167
post #147

Earlier quoted context omitted.

Crackers will just use kvm for virtualisation and dump whatever they want either directly or over SPICE.

Probably. Though I'm still wondering why hasn't Microsoft implemented some kind of roles along Verified Boot. No-one, in Hollywood's view, should be able to watch protected content on a VM. Plus for me it's choppy. Waiting for better virtio graphics drivers for Windows (bugs exist in Visual Studio with HW accel on and there is no 3D support).

Capturing content like that is something you'd do with GPU passthrough, not virtio drivers.

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#168
post #92

Earlier quoted context omitted.

> AMD obviously needs to license the logo for their GPU boxes This poses an interesting question, maybe some of the hobby-lawyers on HN like to chime in and post heir theories :o) Let's assume they print that Logo on their box, call it HDMI in their Windows drivers, but don't do so in their Linux drivers, while it's still a spec-compliant implementation. Would that pose a potential legal problem, and if so why? If it…

You don't just sniff a 48Gbit/s protocol as a random hacker. That's not what happens in the real world. A real-time scope that could do that is in the $1mil dollar range. At best a random hacker will reverse engineer the binary driver enough to make something work in some capacity.

Yes you actually can. It's known that HDMI is TMDS and that the fastest frequency on any given pair is 680MHz and there are a total of 13 data pins (4 pairs + i2c + CEC pin + hot plug detect pin + reserved pin for some special features). A digital logic analyser that can sample at that rate over all 13 pins is going to cost less than a grand. If you stub in some hardware to convert the differential pairs back to a single hi/low signal and drop the optional features of the reserved pin, you can cut that down to 8 signals (or less if your analyzer has dedicated clock signal pins). A DSLogic U3Pro16 is 299usd and can sample 8 signals at 1GHz in buffer mode or 3 pins at 1GHz indefinitely in streaming mode.

If you know roughly what you are looking for, you can set triggers to start sampling when the event you care about starts, that's more than enough to be able to reverse engineer even the most intensive of the existing HDMI spec.

Given that a lot of these graphics cards cost substantially more than 300usd, it's not unreasonable to expect a logic analyzer capable of digesting HDMI to be within their price range.

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#169
post #113

A possible workaround for users is to use an active HDMI adapter, e.g. a USB-C dock or DisplayPort → HDMI converter.

Last I checked those converters do not support HDMI 2.1 features like VRR. If the end output is HDMI 2.0 you might as well skip the middleman.

The Steam Deck dock supports this, for instance.

Re: HDMI Forum does not allow an open source implementation of the HDMI 2.1 spec

#170

Earlier quoted context omitted.

Probably. Though I'm still wondering why hasn't Microsoft implemented some kind of roles along Verified Boot. No-one, in Hollywood's view, should be able to watch protected content on a VM. Plus for me it's choppy. Waiting for better virtio graphics drivers for Windows (bugs exist in Visual Studio with HW accel on and there is no 3D support).

Capturing content like that is something you'd do with GPU passthrough, not virtio drivers.

But Windows knows it's being virtualized. Why doesn't it disable Hi-def output when doing so?
Post reply on HN