Live data from Hacker News

Displayport: A Better Video Interface

hackaday.com

381–390 of 426 posts

Re: Displayport: A Better Video Interface

#381

Earlier quoted context omitted.

It should be a national citizen identity logon system, which a voting web site uses, everyone can vote from home or from a laptop provided by the independent voting facility.

Sounds nice, but computer based voting systems, no matter how secure, clean or simple, are fundamentally opaque to the average citizen. That alone undermines the very democracy it tries to support. Paper based voting systems may be bloody tedious but they’re simple, and anyone can participate. As a programmer myself, I have to say no to electronic voting systems. We need to keep it low tech.

When you vote from home I can show up and put a gun to your kid's head and tell you to vote for Pedro.

When you vote with some sort of association with your name I can look up how you voted after the fact and if you didn't vote for Pedro I can blow up your house.

The fact is that the secret, anonymous ballot is the only valid way of voting.

Re: Displayport: A Better Video Interface

#383

Earlier quoted context omitted.

Maybe I agree with that, but I also know that firewire helped usher in the digital video era. It allowed the transition from tape based acquisition when media cards were prohibitively expensive. Audio/Video/Deck control all down one single cable straight from the camera to the computer was what really kicked the prosumer market into being able to lean closer to pro than consumer. Now that media cards are actually aff…

Yeah, FireWire was a necessity at the time for certain use cases. Even basic consumer digital camcorders required FW400 to pull onto a PC.

FireWire has multiple rates available in the FW400 cable. Consumer digital video camcorders are at 25Mbps for video + 1.5Mb for the audio and use the S100 100Mbit link speed.

Other HD formats like Panasonic DVCPro HD went up to 100Mb video running the same tapes faster.

Re: Displayport: A Better Video Interface

#384
post #367

Earlier quoted context omitted.

I think that you can actually transmit audio, or other displays' signals (DisplayPort Multi-Stream Transport), in place of stuffing symbols.

Afaik its a no-no zone. You can only use blanking periods.

You may be correct (and I was mistaken in my previous post) for audio. The leaked (DP isn't really an open standard) DP-1.2.pdf on glenwing's site says that "The dummy stuffing data symbols during the video blanking periods (both vertical and horizontal) may be substituted either with main stream attributes data or a secondary-data packet", and the public 1.1a PDF indicates similarly.

MST is quite complicated and appears to interleave bytes from different video streams within 64-byte packets (rather than solely during blanking):

> The MTP (Multi-stream Transport Packet) is 64 link-symbol (1 byte of video data or special symbols) cycles (that is, 64 time slots) long, starting with MTP Header in the first time slot (or Time Slot 0), and is constantly transported regardless of the presence/absence of streams.

> The Payload Bandwidth Manager of each uPacket TX in the path from a DP Source to a target Sink device allocates time slots within the MTP to a VC (Virtual Channel) Payload to establish the virtual channel for transporting a stream.

Re: Displayport: A Better Video Interface

#385

Earlier quoted context omitted.

Display port to HDMI cables exist.

Correct, and the article itself stated the conversion (DP source to HDMI sink) is very easy. Still, I can see laptops choosing the most popular port regardless of the possible conversion. Anecdotally when I go to work the cables I see are mostly HDMI. (This is where I’d love to have a Framework-like laptop, where I could just swap between HDMI and DP output with the relevant output module).

> Still, I can see laptops choosing the most popular port regardless of the possible conversion.

Yeah. It's silly that my old Lenovo ThinkPad X220 (bought in 2012) has a full-size DisplayPort port whereas my Lenovo ThinkPad X1 Carbon Gen 7 (bought in 2019) has a full-size HDMI port. It's like it's regressing.

Re: Displayport: A Better Video Interface

#386
post #366

Earlier quoted context omitted.

You are not giving the full picture in this trade. The people making the spec knew the trade well. You add a lot of complexity to a receiver by forcing it to generate its own timing information from whatever video signal is sent. That work has to be done somewhere and it is most robust when done at the source.

That optional infrastructure on the receiving end is already provisioned in the standard in form of eDP PSR (self refresh).

Panel Self-Refesh is an optional feature, is it not?

Re: Displayport: A Better Video Interface

#388
post #115

Earlier quoted context omitted.

TOSLINK/S/PDIF is way out of date and no one uses it any more. Ironically, because it doesn't have enough bandwidth for things like Atmos.

Not entirely true. My house was built with an A/V closet that's not in the living room. To put analog equipment (like a turntable) in the living room where it's used, I convert the analog signals into digital with a $100 A/D converter that sends them over CAT-6 under the house to a decoder that connects to the receiver with Toslink. It works great, and I bought this in the last three years.

Sure, for PCM stereo content it still works perfectly fine. Which is a lot of stuff! But it'd be a poor choice for 5.1 or better today.

Re: Displayport: A Better Video Interface

#389
post #188
post #181

Earlier quoted context omitted.

I have a similar issue with a Nvidia 1080Ti on my old desktop. It's related to the UEFI deciding if the iGPU or the Nvidia GPU should be primary and to disable the iGPU or if the iGPU should stay enabled.

Curious how you went about determining that was the source of the issue.

I'd swap the cables around and could see video from the iGPU output.

Re: Displayport: A Better Video Interface

#390
post #386
post #366

Earlier quoted context omitted.

That optional infrastructure on the receiving end is already provisioned in the standard in form of eDP PSR (self refresh).

Panel Self-Refesh is an optional feature, is it not?

Why isnt there an optional matching DP mode where you could just transfer screen data without timing? Why are you forced to sent fake blanking to PSR displays?
Post reply on HN