Displayport Compliance
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 644 | |
| Author | ||
| License | CC Attribution 2.0 Belgium: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/41146 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | |
| Genre |
FOSDEM 2018261 / 644
2
3
5
6
7
8
10
12
16
18
27
29
30
31
32
34
39
46
47
48
55
57
58
61
64
67
76
77
80
85
88
92
93
98
101
105
110
114
115
116
118
121
123
128
131
132
133
134
140
141
142
143
146
147
149
162
164
171
173
177
178
179
181
182
184
185
187
188
189
190
191
192
200
201
202
204
205
206
207
211
213
220
222
224
229
230
231
233
237
241
242
243
250
252
261
265
267
270
276
279
280
284
286
287
288
291
296
298
299
301
302
303
304
305
309
310
311
312
313
316
318
319
322
325
326
327
329
332
334
335
336
337
340
344
348
349
350
354
355
356
359
361
362
364
365
368
369
370
372
373
374
376
378
379
380
382
386
388
389
390
393
394
396
400
401
404
405
406
407
409
410
411
415
418
421
422
423
424
426
427
429
435
436
439
441
447
449
450
451
452
453
454
457
459
460
461
462
464
465
470
472
475
477
478
479
482
483
486
489
490
491
492
493
494
496
497
498
499
500
501
503
506
507
508
510
511
512
513
514
515
517
518
519
522
523
524
525
527
528
534
535
536
538
539
540
541
543
544
545
546
547
548
550
551
553
554
555
559
560
561
564
565
568
570
572
573
574
576
578
579
580
586
587
588
590
593
594
596
597
598
601
603
604
606
607
608
610
613
614
615
616
618
619
621
623
624
626
629
632
633
634
635
636
639
641
644
00:00
Electronic visual displayWhiteboardForcing (mathematics)Projective planeCoefficient of determinationKernel (computing)Device driverPoint (geometry)TouchscreenView (database)Hand fanComputer animation
00:40
IntelKernel (computing)Device driverElectronic visual displayLink (knot theory)Bit rateSource codeSequenceOptical disc driveFrame problemPerfect groupGraphics processing unitTouchscreenAtomic numberWave packetData recoveryDirected graphSpeciesInformationConfiguration spaceReading (process)Point (geometry)Image resolutionDivisorMultiplication signProcess (computing)TouchscreenGraph coloringExpected valueDifferent (Kate Ryan album)Covering spaceTable (information)Symbol tableLatent heatSpacetimeWhiteboardSource codeLink (knot theory)Electronic visual displayDevice driverArmRight angleCASE <Informatik>Projective planeError messageMessage passingCoefficient of determinationPhase transitionState of matterConnected spaceCodecLaptopObject (grammar)Electronic mailing listSequenceSoftware bugSoftware testingMatching (graph theory)Computer hardware40 (number)Bit ratePlanningField (computer science)Event horizonMappingLevel (video gaming)Equaliser (mathematics)SynchronizationGradientMaxima and minimaAsynchronous Transfer ModeLoginKernel (computing)SkewnessSet (mathematics)Perturbation theoryFreewarePattern languageDigital rights managementForm (programming)CountingParameter (computer programming)Mathematical optimizationInterrupt <Informatik>Tap (transformer)Atomic numberMultiplicationNumberoutputReference dataComputer animation
09:01
Perfect groupLink (knot theory)Gamma functionAsynchronous Transfer ModeComputer configurationGraphics processing unitParameter (computer programming)SpacetimeSoftware testingIntelOpen setWhiteboardSystem programmingKernel (computing)Event horizonAsynchronous Transfer ModeLink (knot theory)Image resolutionPulse (signal processing)Wave packetCategory of beingPoint (geometry)Bit rateProjective planeMultiplication signPatch (Unix)Suite (music)Phase transitionIntegrated development environmentSpacetimeKernel (computing)TouchscreenCountingInformationWhiteboardCASE <Informatik>Device driverPhysical systemVideoconferencingSoftware testingMereologySet (mathematics)Game controllerCommitment schemeLaptopConnected spaceMathematicsParameter (computer programming)Combinational logic2 (number)Different (Kate Ryan album)Type theoryMaxima and minimaOpen sourceAtomic numberEntire functionElectronic visual displayComputer configurationComputer hardwareNormal (geometry)Physical lawView (database)Symbol tableGoodness of fitHypermediaFile viewerMessage passingMobile appOnline helpBuildingMetropolitan area networkPlanningVideo gameLatent heatComputer animationProgram flowchart
17:22
Data storage deviceSoftware testingOnline helpRight angleBasis <Mathematik>Point (geometry)Pay televisionVotingWhiteboardComputing platformSpacetimeAndroid (robot)Multiplication signTotal S.A.Source codeScaling (geometry)Category of beingCASE <Informatik>AreaRevision controlPerturbation theoryComputer hardwareSurfaceSuite (music)Computer animation
21:36
PressureKernel (computing)CollaborationismService (economics)Gamma functionProgram flowchart
Transcript: English(auto-generated)
00:05
So, hi again. My name is Mansi Naware, and I work at Intel's i915 graphics kernel driver team. I've been on that team for about two-and-a-half years, and today I'm going to talk about actually my very first project on the team
00:22
which was DisplayPort compliance. From the user's point of view, yes, it meant fixing the black screens with DisplayPort, which maybe it happened just now. I don't know. I shouldn't have because I have the latest kernel with the fixes.
00:42
So has anybody else experienced this before with the DisplayPort or Mini DisplayPort, just a black screen? Okay. So good. So I guess you can relate to the problem that I'm talking about here. When I joined the team, there were almost I think 97 percent of
01:01
the free desktop bugs that we had on the display side were because of the black screens, or the hot plug issues, and connect multiple monitors, and there's just no display. So the goal of my project was to make the DisplayPort driver DP compliant and upstream the solution.
01:24
So let's start with the basics. So what happens when you connect a DP cable? So you have the DP source on one end, which is your PC and the DP monitor on the other end. So when you connect it with the DisplayPort cable, the first thing that happens is
01:41
the hot plug detects signal that the sync device sends to the source device. It's just an interrupt signal saying, hey, there's a new connection. After that, the source is going to initiate the DisplayPort configuration data register read-writes, through which it's going to start reading the capability supported by the monitor.
02:01
It will know the resolution supported, the link parameters that are supported by the sync device. Once it has negotiated these parameters between the source and the sync device, then it's ready to encode the data and start sending it on the actual cable.
02:21
The very first thing that happens when you connect the DisplayPort cable is this negotiation sequence between the source and the sync device, which is called as the DisplayPort link training. So, yeah, the first signal is the hot plug detect signal, then the source will start the link training. First, it has to go through the clock recovery sequence,
02:43
where it sends the known training data patterns to kind of lock the clocking information on the DisplayPort receiver end. Then it's going to send another known training pattern sequence, but this time it's going to send it
03:01
with the known skew between the two lanes. So this data is used on the other end to find out the interlane alignment and get the mapping of how the data symbols are sent between the two lanes on the DisplayPort cable. After these two sequences succeed, the source and the sync device kind of lock
03:21
a particular link rate and lane count, and then they can start sending the data at that specific link rate and lane count. And we say that the link is ready, and that's when it will start sending the data and you see the display on the monitor. So what was our plan for testing
03:42
the DisplayPort compliance? So the plan was to use the third-party device, DPR120, which is certified by VESA, to run the exhaustive test suite, the compliance test suite, which makes sure that the driver is compliant with the specification.
04:01
So it basically acts as a reference sync device. You connect the device under test, the laptop, to the DisplayPort input of DPR120, and the DPR120 is going to say, okay, display this specific data pattern at this resolution. And the laptop will start sending the data,
04:22
DPR120 taps the information on the DisplayPort cable, and it's going to compare that with the reference, CRC values, reference data patterns, and if it matches, then yes, it passes the test. So a lot of these tests here try to verify that link training is going to pass in different scenarios.
04:43
Like, for example, if the first phase of clock recovery fails, then the DPR120 actually is going to try to induce that failure and see if the device can recover from that and still send the data after the specified number of retries,
05:00
specified by the DisplayPort spec. So the goal was to run all these tests and make sure that the driver was actually passing all those link training tests, and it was able to recover from the failures. So going back to the basics, right? So what was the existing state
05:22
of the atomic kernel mode setting? So what does it do when you connect the DisplayPort cable? The user space is going to form the list of parameters, the properties, and send that to the kernel. Then the first step that the kernel does is forms the state of the device.
05:41
It forms the state for the different DRM mode objects depending on the requested mode. This is the atomic check phase, and in this phase, it's going to try and validate the mode that is being requested. So in this phase, it will, let's say, get the 4K mode, and it's going to see whether that mode is going to be supported by the hardware,
06:01
by the available clock, by the link parameters of the DisplayPort cable. If it can actually support that resolution, then it will go to the commit phase. And in this phase, it's going to take all the data and write it to the hardware registers. Since this is the phase where it does all the writes
06:21
or the hardware update, this is where the link training is going to happen because it has to actually send the data symbols. And that's when you're going to start seeing the display on the monitor. So I thought, okay, the atomic mode setting is validating the state in the atomic check phase, and it's then going to write everything to the hardware.
06:45
So because it's already validated, it should actually work, and everything should just work fine. So I thought, okay, yes, problem is solved, but did we actually fix the black screens at this point?
07:01
So yeah, I ran the test suite, and yes, sure, when DPR120 tried to introduce the link training failures, the driver was not able to recover from the link training failures, and it was just a black screen. So let's see what the problem was. So just a simple scenario again.
07:20
You have the sync device connected to the source device. It sends the hot plug detect signal. Let's say it requests this mode at 60 hertz. So the first phase is going to be the kernel is going to set up the CRTC, set up the pipe for a specific configuration.
07:41
It will start with the optimum link rate and lane count at this point, and see if that supports the requested mode, and configure the pipe for that specific link rate and lane count. But it hasn't actually sent any symbols on the cable, so it hasn't validated whether it's going to be able
08:03
to send those symbols on the cable, if it's going to work or not. That's going to happen in the commit phase, where it actually sends those training pattern symbols, and it goes through clock recovery and channel equalization. And what happens if at that point the link training fails? And that's when you see a black screen.
08:22
So the existing state of the driver at that time, it would just get a black screen, and the D message logs would just say, okay, error, link training failed. But there was literally no information going back to the user space, or the kernel wasn't doing anything to recover from this mode failure. And that's when we were getting those black screens.
08:45
So what did we do? How was this fixed in the driver to actually be able to recover from such failures, which happened only at the last stage of the atomic kernel mode setting? So we were here, it requested a specific mode,
09:03
and let's say, first it tried to link train at the maximum link rate and lane count for 5.4 gigabits per second and four lanes, and that failed. So once that fails, so we introduced a new property for the DRM connector, which would indicate
09:20
the status of that specific link. So at that point, the kernel knows that link training failed at 5.4 gigabits per second, four lanes, so it's going to immediately fall back to the next lower values of the link rate, which is HBR, which is 2.7 gigabits per second,
09:41
and four lanes. So first it will go down, fall back the link rate, and try again. And it keeps doing that until basically the link training succeeds. So it falls back, and at the same time, it's going to set the link status property to bad and then send a U event notification to the user
10:01
space saying that, OK, something went wrong in the configuration, and that specific requested mode did not work. So at that point, user space retries the mode set at the same resolution first, but then it might happen that because we fell back to the lower link rate and lane count values,
10:21
it might prune the mode. So at that point, the user space has to get the connector information again, get the new modes, and then try the mode set at the next available, next lower resolution. So at this time, the kernel gets the mode set request. It's going to go through the same phases, but now this time, it's training at the lower values.
10:43
And the link training is hopefully going to succeed, and we get a successful mode. So this actually happens for all the combinations it does for the link rates all the way to RBR, 1.62 gigabits per second. If that doesn't succeed, then it starts reducing the lane count, and it
11:01
goes all the way to one lane. So it basically tries all the combinations and keeps reducing the resolution until it can show something on the screen, which is even if it's really small resolution, it's better than the black screen. So why was this needed? So the basic loophole here in the atomic kernel mode setting
11:24
was that the failure is always an option. And it was assumed that the atomic commit phase will always pass, and the mode was always guaranteed at that point. But with link training, when we are dealing with the actual hardware, it guarantees the requested mode, yes.
11:42
But at that point, it's only checking against the GPU parameters, but not the actual physical cable. So link training can still fail, and the atomic commit can still fail. So we do need to handle this case. So this link training failure is asynchronous, because the link might be working and ready
12:03
in your transmitting symbols, but it can fail at some point when it's up and running, displaying something. So you need a way to asynchronously send some notification to the user space at any time it detects that the link is not working correctly.
12:20
Also, it helps because atomic allows the non-blocking commits. So what that means is it's going to do the mode set and return the control to the user space, but we don't know whether the atomic commit has completed. So the user space still doesn't know if it has successfully been able to display something,
12:41
and the atomic commit phase is successful. So in that case, also, we need some way to asynchronously notify this to the user space. So this is how we basically tested the entire stack and made sure that the newly introduced property
13:03
and the way of handling the atomic failures was actually validated through the entire stack, and the whole stack was able to recover from this mode set failure. So we use the DPR120 device to induce those failures
13:21
in the link training. So first, it sends the long pulse. It requests a specific mode. The kernel at that point is going to validate the mode link train at a certain rate. Once it fails, it's going to fall back, set the link status property to bad, and send the U event. At that time, we did make changes
13:41
to both the XF86 video Intel and the mode setting driver to actually handle this newly introduced property. So it keeps looking at the link status property, and as soon as it sees that it's bad, then at that time, it's going to request a new mode set at the same resolution.
14:00
But like I said, that resolution might actually get pruned, because now the link parameters have changed, and it might not support that same resolution. So it sends the XRANDAR event up to the desktop environment. And Martin actually wrote this app, AutoRANDAR, to constantly listen to those RANDAR events.
14:23
And so every time it gets that event, it's going to re-probe the connector, get the mode information, and then redo the mode set at the next available resolution. So this was the way we were able to test it across the stack.
14:41
All the changes are upstreamed for i9-15 as well as the X server, but I still need to connect with the Gnome-KD folks to do these changes in the desktop environment, because otherwise the whole stack is not going to be compliant at this time.
15:03
I also wrote a tool. It's upstreamed in the Intel GPU tools now. So it's a DP compliance tool for fully automating this compliance testing. It does need having DPR120 connected to the DUT,
15:22
but after that, it just gets the test request, handles the test request from the DPR120, runs the entire suite. And it's going to keep the log of what tests are passed and what failed. So that was a good way for us to do our pre-merge
15:41
and post-merge testing at this point. But one of the next steps, future steps for us, is to move this whole testing infrastructure to the open source hardware, Google's Chameleon board. With that, the idea is we will be able to test it with a lot more corner
16:01
cases with different types of external displays. And so we'll replace the DPR120 with Google Chameleon board. We would have to move the entire compliance test suite onto the Chameleon board, which is going to be a big effort, because it
16:22
has to be certified by VESA to say that, OK, this is a reliable test suite that you can run and say that the driver is DisplayPort compliant. And then eventually, the goal is once we are able to move everything to the Chameleon boards, we can have that as part of our CI system so that for every DisplayPort,
16:46
every laptop with a DisplayPort, we have this connected. And we always run the compliance suite. So anything that any patch that gets submitted, it will run against the suite. And we'll make sure that it's not breaking the link training.
17:01
So that's all I had. And this was definitely not a one-man project. I wouldn't have been able to finish this without help from the community, from reviews from everyone. So yeah, thanks to everyone for reviews and suggestions.
17:23
Thank you. Questions? Any questions? So what Linux versions do you talk about here? So for 15?
17:40
So what version does have the fixes? Oh, so it's in the 4.12 and XR work, yeah. I didn't read the answer. Yep. What's the real answer to this? So it is not there on Valent. So that's one of the goals to actually scale the solution to Valent and even on Android Surface
18:05
Plinger. Because until then, this property is going to be there. But if the user space does not look at the property and does not handle it, then it's still going to basically fail at that time.
18:20
So yeah, I'm trying to reach out to other user space communities and help out to scale this feature.
18:46
So far, we have just ordered the Google Chameleon boards. We have the budget for that, right? Yes. But no resources are allocated to that.
19:03
So yeah, it's going to take a while. But we will work on that in 2018. And again, I would need help from the community. I know Lyud Paul from Red Hat, she's done a lot of work with testing DPMST and other corner
19:25
cases with hot plugs using the Chameleon board. So I'm going to reach out to her and yeah. Yeah, anybody can order it. I think it's worth it.
20:26
And replacing that, the DPR120 with Chameleon boards is way cheaper because DPR120, the licensing fees are ridiculous, $5,000 or something. So we definitely can't have more than two DPR120s.
20:45
So with DPR120, there's no way we can integrate that with CI. So we would need a solution on Chameleon boards. DP 1.2 and 1.3, we haven't tested DP 1.4 yet.
21:09
So DPR120, they have added new tests for DP 1.4 support. They are adding. But we haven't ran that compliance test suite yet.
21:21
So they didn't have hardware RCTS support? Yes, yes. Yeah. For the newer platforms too. OK? Thank you.