<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Displayport&#8217;s M and its Mvid fields: Timestamp or divider?</title>
	<atom:link href="http://billauer.se/blog/2015/06/diplayport-mvid-nvid/feed/" rel="self" type="application/rss+xml" />
	<link>https://billauer.se/blog/2015/06/diplayport-mvid-nvid/</link>
	<description>Anything I found worthy to write down.</description>
	<lastBuildDate>Thu, 26 Mar 2026 13:15:15 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.1.2</generator>
	<item>
		<title>By: eli</title>
		<link>https://billauer.se/blog/2015/06/diplayport-mvid-nvid/comment-page-1/#comment-1283</link>
		<dc:creator>eli</dc:creator>
		<pubDate>Tue, 01 Aug 2017 09:46:43 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=4697#comment-1283</guid>
		<description>Thanks.

I&#039;m sorry, but it was two years ago, and I&#039;ve been lucky enough not to deal with Displayport since. So I don&#039;t remember much about it at the moment.</description>
		<content:encoded><![CDATA[<p>Thanks.</p>
<p>I&#8217;m sorry, but it was two years ago, and I&#8217;ve been lucky enough not to deal with Displayport since. So I don&#8217;t remember much about it at the moment.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Raanan</title>
		<link>https://billauer.se/blog/2015/06/diplayport-mvid-nvid/comment-page-1/#comment-1282</link>
		<dc:creator>Raanan</dc:creator>
		<pubDate>Tue, 01 Aug 2017 08:10:41 +0000</pubDate>
		<guid isPermaLink="false">https://billauer.se/blog/?p=4697#comment-1282</guid>
		<description>Hi Eli,

Great blog, great article. What I find peculiar in this pixel packing approach, is that in the blanking regions we&#039;re basically transmitting dummy symbols (not even packed in TUs if I am not mistaken) and the whole M_vid counting is rather theoretical / arbitrary there. For example, should we still &quot;mimic&quot; the stuffing or should we increment M on every link clock cycle? 

Moreover, if I understand correctly, things need to be set such that at each scan-line the number of stream pixels will end before the link symbols so that some margin will be left for the asynchronous corrections. What&#039;s the size of this margin? Where would it affect the receiver? (a large margin would mean that M_vid will not change over these intervals of every line - is that an issue?)

Perhaps I am confused about who this control-flow mechanism work in the async mode..</description>
		<content:encoded><![CDATA[<p>Hi Eli,</p>
<p>Great blog, great article. What I find peculiar in this pixel packing approach, is that in the blanking regions we&#8217;re basically transmitting dummy symbols (not even packed in TUs if I am not mistaken) and the whole M_vid counting is rather theoretical / arbitrary there. For example, should we still &#8220;mimic&#8221; the stuffing or should we increment M on every link clock cycle? </p>
<p>Moreover, if I understand correctly, things need to be set such that at each scan-line the number of stream pixels will end before the link symbols so that some margin will be left for the asynchronous corrections. What&#8217;s the size of this margin? Where would it affect the receiver? (a large margin would mean that M_vid will not change over these intervals of every line &#8211; is that an issue?)</p>
<p>Perhaps I am confused about who this control-flow mechanism work in the async mode..</p>
]]></content:encoded>
	</item>
</channel>
</rss>
