Talk:DisplayPort/Archive 2

Archive 1

Archive 2

HDMI comparison section confusing

The section comparing DisplayPort with HDMI seems very unclear to me. Could someone with better knowledge on the topic perhaps revise it? 166.66.39.90 (talk) 17:28, 5 January 2018 (UTC)

Note that I also found this section to be confusing. If someone would like to incorporate more of the following article on a true comparison, please feel free to do so. This Wiki page was not informative enough in this aspect, so I continued to search and found this: https://www.pcworld.com/article/2030669/laptop-accessories/hdmi-vs-displayport-which-display-interface-reigns-supreme.html50.245.34.78 (talk) 00:08, 6 April 2018 (UTC)

This section previously stated that the multiple display capabilities of DisplayPort are "in the opposite, less "consumer"-oriented configuration: ..." I didn't understand this at all since many consumers want multiple monitors from a single computer nowadays. I didn't realize what was meant by the "opposite direction" - opposite of what? I realize now that this user had meant that the multiple display capability is not a "multiple input" capability, meaning that it doesn't allow daisy-chaining of many inputs to one display. I don't find that this needs to be stated (since this is speaking about multiple DISPLAYS), but if someone else here feels it should be included then feel free to add something like the following sentence to the end of the revised paragraph (5 April 2018): "However, it is not meant for having multiple input devices on a single display." 50.245.34.78 (talk) 00:08, 6 April 2018 (UTC)

Noted

Regarding this edit: https://en.wikipedia.org/w/index.php?title=DisplayPort&oldid=847570555

Firstly, no I didn't add it to a different section of text. It was removed in three instances and I restored one of the three. The other two I left removed because I agree it works fine without them. However, the second instance does not work with the phrase removed directly.

MOS:NOTED forbids the phrase "Note that" specifically because it addresses the reader directly. The phrase "it should be noted" does not violate this. The cited essay WP:NOTED recognizes this distinction. (though it also claims "it should be noted" violates the MOS:NOTED policy anyway, but doesn't explain in what way, since MOS:NOTED only brings up the point about the direct address.)

From WP:NOTED:

It should be noted violates the Wikipedia Manual of Style guidelines MOS:NOTED and WP:EDITORIAL. The variations remember that, note that, and note: are direct instructions to the reader, additionally violating the style guideline WP:YOU.

From MOS:NOTED:

Avoid such phrases as remember that and note that, which address readers directly in an unencyclopedic tone. They are a subtle form of Wikipedia self-reference. Similarly, phrases such as of course, naturally, obviously, clearly, and actually make presumptions about readers' knowledge...

In any case, this is somewhat irrelevant. As I said, I have only re-added it in the interim because the sentences are confusing without it. If "it should be noted" is removed, then the sentences need to be reworked to make sense without it. Pending someone coming up with a better way of constructing the sentences, the phrase should be left in, as it is more important for the article to make sense than to be MOS-compliant in the meantime. GlenwingKyros (talk) 15:56, 26 June 2018 (UTC)

I took a stab at it with these edits. After re-reading the passage now, I see no reason to include the phrase "it should be noted" or anything along those lines. Also in regards to the MOS:NOTED comments above, keep in mind that not every example is going to be listed in the guideline. Also, regardless if it's a violation or not, there are better alternatives to using passive constructs like that. --GoneIn60 (talk) 21:13, 26 June 2018 (UTC)

Thanks. I understand not every example will be listed, I was just pointing out that the passage I quoted from WP:NOTED specifically indicates that "Note that" violates the direct address guidelines while "it should be noted" does not. Since MOS:NOTED only forbids phrases on the grounds of direct address, it doesn't seem to apply to "it should be noted", at least if the WP essay's position is to be taken. Anyway, I agree with replacing it, just not with the flat removal of it in that instance. GlenwingKyros (talk) 21:54, 26 June 2018 (UTC)

Regarding MST adapter compatibility

Just noting things here for informational purposes; support for adapters chained from MST devices appears to depend on the device.

I have two monitors that support daisy-chaining, the Dell U2414H and UP2516D. I also have a 2-port Accell MST hub, the K088B-004B. I have tested a number of adapters on these devices, including:

• a DP to SL-DVI passive (dual-mode) adapter
• a DP to HDMI type 1 passive (dual-mode) adapter
• a DP to VGA active adapter
• a DP to Dual-Link DVI active adapter (VisionTek 900639)
• a DP to HDMI 2.0 active adapter (Plugable DP-HDMI Rev. B)

None of these adapters worked when trying to chain them from the U2414H's DP output port. All of them worked when chaining them from the MST hub. And from the UP2516D, the active adapters worked but the passive adapters did not. So it's quite a mixed bag.

As per WP:VERIFY, this information cannot be used for the article, I'm just including this here for clarity on the situation. Adapter compatibility with MST appears to be device-dependent. GlenwingKyros (talk) 08:16, 10 July 2018 (UTC)

Display Port v1.4a?

Nvidia's upcoming RTX graphics cards will support Display Port v1.4a which supports an 8k resolution at 60Hz. There is no mention of a Display Port v1.4a in this article though. — Preceding unsigned comment added by 58.96.42.36 (talk) 05:38, 12 September 2018 (UTC)

It apparently was released in April 2018, but there's no official announcement from VESA. It's difficult to find what changes were added but it seems to be very minor. The maximum transmission mode is still the same, HBR3. If I were to guess, it's likely just a protocol update, to add the latest HDR standards and DSC 1.2a, things like that. But I'm just speculating. Since they announced at the beginning of the year "we're working on a new version which will have way more bandwidth", they probably didn't want to make a big announcement about a new DisplayPort version when it's only a minor intermediate update.

https://www.paradetech.com/parade-technologies-introduces-new-generation-displayport-1-4a-to-hdmi-2-0b-protocol-converter/

DisplayPort version 1.4a is the latest version of the DisplayPort standard published by VESA in April 2018. It includes the implementation of DSC (Display Stream Compression) and the HBR3 (High Bit Rate 3) data rate of 8.1 Gbps (Gigabits-per-second); used together, these features enable the ability of the PS186 to deliver full HDMI 2.0b performance from two lanes, or channels, of DisplayPort. The PS186 also supports HDMI CEC data over the DisplayPort AUX Channel, HDCP 2.2, HBR audio formats, up to 12-bit color components, as well as “Horizontal Blanking Expansion” as specified in DisplayPort v1.4a.

There's very little information, so I don't know what we could put in the article other than the fact that it exists... The DisplayPort FAQ has also been updated to reflect the existence of DP 1.4a (https://web.archive.org/web/20180906093047/https://www.displayport.org/faq/), but it appears that all the FAQs are the same, they just changed all the mentions of "1.4" to say "1.4a" instead, there's no indication of what actually changed between versions 1.4 and 1.4a. GlenwingKyros (talk) 15:44, 12 September 2018 (UTC)

Rewrote a highly questionable sentence

Hi.

The article contained the following sentence that violates WP:NPOV and WP:V in a rather sneaky way. You cannot tell that it is problematic without examining it.

The specification for DisplayPort Alternate Mode over Type-C was published in 2014; PC, Mac and Chromebook products implementing it started releasing in 2015 and as of 2018 many are available. The specification for HDMI Alternate Mode over Type-C was announced two years later at the end of 2016.

Now, let's take a look at its problems:

• The "PC" link actually goes to Dell XPS. (Violates WP:SUBMARINE.) This article does not comment on whether or not PCs or Dell XPS devices implemented this specification in 2015.
• The "Chromebook" link actually goes to Chromebook Pixel. (Violates WP:SUBMARINE.) This article does not comment on whether or not the Chromebook brand or the Chromebook Pixel devices implemented this specification in 2015. USB-C is mentioned only once.
• The "Mac" link actually goes to MacBook (12-inch). (Violates WP:SUBMARINE.) This article actually does mention USB-C DisplayPort 1.2 Alternate Mode. Still, it that does not rule out there being another Mac or non-Mac product released earlier and having implemented said specification. It is an informal fallacy.
• "...as of 2018 many are available": "Many" is subjective; it is a weasel word. Is four 2-in-1 devices considered "many"? Apart from that, the whole phrase assumes that the "List of devices with video output over USB-C" article has, without fail, listed all such devices. I doubt it has; in addition, most of those listed items have no release dates. But the worst problem of all is that, right now, the number of smartphone products listed in that article is greater than any other device type combined. Smartphones are the only devices in that article that have release dates. Ironic, isn't?

37.254.78.42 (talk) 05:39, 26 June 2019 (UTC)

DisplayPort 2.0 data rate figures

Currently there is a small discrepancy with the numbers. UHBR 10, 13.5, and 20 modes have raw bit rates of 40, 54, and 80 Gbit/s across all lanes. When 128b/132b encoding is applied:

• 40.0 × (128/132) = 38.78 Gbit/s
• 54.0 × (128/132) = 52.36 Gbit/s
• 80.0 × (128/132) = 77.57 Gbit/s

However, VESA's press release states a maximum of 77.37 Gbit/s for UHBR 20, and the Anandtech article has a table stating 38.69, 55.22, and 77.37 Gbit/s. Apparently this is because FEC is mandatory in DP 2.0, and that consumes a small amount of bandwidth. https://www.anandtech.com/show/14590/vesa-announces-displayport-20-standard-bandwidth-for-8k-monitors-beyond

FEC in DP 1.4 uses Reed–Solomon (254, 250) code according to Hardent ( https://www.hardent.com/ip-products-ecc-reed-solomon-fec/ ), but that operates on the 10-bit symbols obtained from the 8b/10b encoding used by DP 1.4. DP 2.0 must use a different implementation. Until there is specific information about the FEC implementation in DP 2.0, we cannot calculate the data rates numerically to show how the data rate numbers are derived, but in any case, we should use the figures given by the Anandtech article. GlenwingKyros (talk) 03:11, 2 July 2019 (UTC)

Humbly, a Critique

As a non-specialist in computer technology, while these specs are undoubtedly vastly important details, their preponderance in this article completely leech any meaning for the layperson away from being able to comprehend anything. The use of abbreviations, while certainly viral for a technical understanding of the topic, completely lose the reader who might be unfamiliar with them and does not seek in an encyclopedia entry to reference what they mean again and again. Long story short, I would consider rewriting portions of this document as they would never appear in any other encyclopedia. This level of detail is best left to technical manuals or links for people to take deeper dives. 2605:E000:FF08:2A00:D449:6A42:524B:5083 (talk) 19:17, 18 September 2019 (UTC)Gene Hetzel2605:E000:FF08:2A00:D449:6A42:524B:5083 (talk) 19:17, 18 September 2019 (UTC)

Can you provide specific examples of sections or paragraphs which are overly technical, or use uncommon abbreviations without wikilinks or full-form-on-first-appearance? Overall, I can certainly agree to some extent; some sections like the entire Overview section focus on details that are largely irrelevant and not of interest to most readers, and should probably be relocated elsewhere. The Overview section should focus on basic capabilities (it can transmit video, audio, it can do this and that, etc.). Some sections (like cables and connectors) I've already rewritten to try to state the facts as clearly as possible, organize the presentation of information so that the details of interest to most people are stated first, etc., and I think those parts of the article are in a good state as is. Without clarification on which parts of the article you feel need work, it's hard to comment any further than that. GlenwingKyros (talk) 19:37, 18 September 2019 (UTC)

DisplayPort developers in first sentence incorrect

The first statement is not correct:

DisplayPort (DP) is a digital display interface developed by a consortium of PC and chip manufacturers (particularly Maxell, Lattice, Philips and Sony)[1] and standardized by the Video Electronics Standards Association (VESA).

Should be: DisplayPort (DP) is a digital display interface developed by a consortium of PC and chip manufacturers and standardized by the Video Electronics Standards Association (VESA).

Maxell, Lattice, Philips and Sony were not the lead companies for developing DisplayPort. The companies that worked on DisplayPort are listed later in the article.

Bill Lempesis Executive Director, VESA (the standards organization that developed DisplayPort) executive@vesa.org — Preceding unsigned comment added by 98.210.70.181 (talk) 19:47, 17 January 2020 (UTC)

I have removed the company names from the sentence now. The cited source was this PDF: https://www.mpegla.com/wp-content/uploads/displayport-att1.pdf

It appears that someone made the assumption that they were the principle developers, based on the number of related patents held by each of those companies according to the document. GlenwingKyros (talk) 07:09, 18 January 2020 (UTC)

They were added in this edit along with the "Patent holders" section. That should go as well, as probably a lot of other technical information in this article. Tech specs without context or sources that explain their relevance are unsuitable for an encyclopedia. This isn't a technical whitepaper, and Wikipedia is not an indiscriminate collection of information. I'm removing that section for starters, but a lot more cleanup is still needed here. --GoneIn60 (talk) 07:38, 18 January 2020 (UTC)

DP vs HDMI cable max length incorrect

The article states

HDMI can accept much longer max cable length than Displayport (30 meters vs 3 meters)

However a quick search reveals many passive 15m cables and the list of VESA certified cables has up to 18.8m cables for example 18.8m cable from ELKA. Active optical cables can go even longer, such as 100m — Preceding unsigned comment added by 2001:7D0:8417:3A80:D959:9628:70B9:3472 (talk) 16:16, 27 January 2020 (UTC)

Neither standard specifies a maximum cable length, so there should be no statements to that effect of any kind. GlenwingKyros (talk) 20:18, 26 February 2020 (UTC)

Actually, it's just HDMI that doesn't specify a maximum. The DisplayPort specification actually does. According to this source, "DisplayPort specifies a maximum cable length of three meters for copper and fifteen meters or more for fibre optic". More information about these limitations, such as higher risk of signal degradation as length increases, is discussed in greater depth at the following sources:

• DisplayPort vs HDMI -- Tech Advisor
• DisplayPort 1.3 vs HDMI 2.0 -- Interview with an electrical systems manager at Planar

The type and quality of the cable play crucial roles, which is also why you will read and hear differing opinions at times. Also, despite being able to run cables longer than the specification's recommendation, what a lot of sources aren't telling you is that the resolution in their test case may only be 1080p (or even lower). So watch out for that. --GoneIn60 (talk) 08:28, 27 February 2020 (UTC)

I have read the DisplayPort standard, there is no maximum length specified, and there are products on the DP certified list that are longer than 3 meters ([1]). Those sources are factually wrong, regardless of authority, and I wonder if they got their information from this very page (which used to say there was a 3 meter limit until I removed it some time ago). I'm aware of course that signal integrity becomes more difficult to maintain as length increases, and there may be practical limitations on how long cables can be (so a statement like "DisplayPort cables typically are less than 3 meters in length" could work, although I don't really agree with that, and it would need a source). Standards don't specify things in terms of length as a proxy for signal integrity, they just specify things in terms of signal integrity directly (the signal at the receiving end must be no more than 3 dB drop at X frequency or whatever, the return loss must be such and such, etc.). Those are the parameters a cable must meet. The physical construction isn't dictated, as long as it meets the mechanical stress requirements. How you achieve the signal requirements is up to you, maybe as a matter of practice most cables are no more than 3–5 meters due to the difficulties, but if you can manage to somehow figure out a way to pass an acceptable signal over a 100 meter cable, they aren't concerned with how you did it, just that your cable passed the certification test conditions, and that's all there is to it. There's no sentence in the DisplayPort standard that says "cables shall not be longer than 3 meters". GlenwingKyros (talk) 08:43, 27 February 2020 (UTC)

Did you happen to notice that the source I quoted above says up to 15m for fibre-optic? That might explain the longer cables you're seeing on the DP certified list. And while Tech Radar is a solid, reliable source in most cases, I would definitely think an engineer for Planar would know what they're talking about without having to rely on Wikipedia. In the interview, they are evidently speaking from experience. I don't have the time to research it any further at the moment, but I'll try to circle back at some point. I don't have a strong opinion either way at the moment. --GoneIn60 (talk) 15:21, 28 February 2020 (UTC)

No, it's a standard 5 meter HBR3 certified cable. Near the beginning of the standard, in the "objectives" section, it lists full bandwidth over a 3 meter cable, and lower formats over a 15 meter cable as an objective of the standard. I think some people may have misinterpreted that. But those are not dictating maximum limits on cable length, there is no such restriction. They're just objectives. Like I said, if someone can come up with a 5 meter cable assembly that passes the signal parameters, it can be certified as evidenced by many examples in the VESA product database. GlenwingKyros (talk) 17:17, 28 February 2020 (UTC)

Use of GT/s

Regarding this edit; While making a distinction between transmission bit rate and the video data rate is a good idea, I don't think GT/s really works here. Typically GT/s is used to talk about synchronized operations across a whole interface, not considering the width of the interface. For example, in RAM, a 64-bit wide bus is used, so each transfer operation is 64 bits of data. That's still one transfer operation, not 64 operations. So RAM operating at 1600 MHz DDR would be 3200 MT/s (204.8 Gbit/s since each transfer is 64 bits of information), rather than 204.8 GT/s. In the case of the DisplayPort standard, since there are 4 lanes operating concurrently, in HBR3 mode it would be 8.1 GT/s per lane and still 8.1 GT/s across the interface, not combined into 32.4 GT/s, and using it that way would probably just add more confusion rather than reduce it. Unfortunately 32.4 Gbit/s is still the proper way of representing the bit rate, because it is communicating digital bits; they just don't represent information in the data stream, and using Gbit/s is consistent with the terminology/units used in all other sources including VESA. GlenwingKyros (talk) 17:57, 28 February 2020 (UTC)

The problem is that the transferred symbol does *not* in itself directly represent information. It is therefore not a bit, it is just a binary symbol representing an information density of less than a single bit! You do have a point that adding up the lanes might be a bit weird. The most accurate unit would likely be to use GBd/s (giga baud per second), creating the distinction and also not running into the problem of whether the lanes may be counted independently. — Preceding unsigned comment added by 2001:16B8:2623:4EF0:0:0:0:381 (talk) 13:50, 29 February 2020 (UTC)

It is still a binary digit, hence a bit. You might argue that bits that aren't part of the data stream don't really count as bits but I think it's a fairly trivial semantic point, it doesn't make a difference in any practical sense. Baud could be used, although may be problematic later if they begin using multi-level encoding where one symbol represents multiple bits, and is also unfamiliar to most readers and isn't used by any source. I've considered both these units in the past, but I think Gbit/s is the best we can do for now, as it's consistent with all other sources on the subject (and most other subjects for that matter), and I think the explanations given are adequate to distinguish what the different rates represent. GlenwingKyros (talk) 18:08, 29 February 2020 (UTC)

How to calculating Data rate ?

It would be great, if it would be visible, how the Data rate in this table were calculated. For exaple if someone want to calculate another resolution or with 10/12 Bit instead of 8 Bit.

It already explains in the footnote on data rate. GlenwingKyros (talk) 15:36, 4 September 2021 (UTC)

Errors in "Refresh frequency limits for HDR video" table

UHBR 10 provides bandwidth of 38.69 Gbit/s. The data rate required for 4K 144Hz and 5K 85Hz are 39.19 and 39.75 Gbit/s, respectively, both of which are over the UHBR 10 bandwidth. However, they are marked as "Yes" under the table, without any note that it is possible with non-standard timings. Assuming the bandwidth numbers are correct, either it's a clear no, or it's a yes but with the non-standard timings. AP 499D25 (talk) 14:47, 28 October 2022 (UTC)

Fixed  — Glenwing (talk) 17:13, 28 October 2022 (UTC)