Achieving DisplayPort compliance

At the X.Org Developers Conference, hosted by Google in Mountain View, CA September 20-22, Manasi Navare gave a talk about her journey learning about kernel graphics on the way to achieving DisplayPort (DP) compliance for Intel graphics devices. Making that work involved learning about DP, the kernel graphics subsystem, and how to do kernel development, as well. There were plenty of details to absorb, including the relatively new atomic mode setting support, the design of which was described in a two-part LWN article.

Navare has been at Intel for three years; she started on the Chrome media team, but moved to the kernel graphics team after about a year. She has been working on the i915 driver, mostly on DP compliance. It has been a lot of fun learning about all of the different pieces that were required, she said. Most in the room responded positively to her query about whether they had DP, mini-DP, or USB Type-C connectors on their laptops. Many of those also agreed that they had seen the dreaded "random black screen" when connecting displays using those connectors. Those failures generally do not come with any information in the kernel logs, which is frustrating. She said the goal was to get rid of those random failures and the make the graphics hardware and software DP compliant.

Under the bus

She was "completely new" to the subject when she was "thrown under the bus" on this project, she said with a laugh. She was tasked with fixing the driver and making it 100% DP compliant but, being new, she didn't know where to start or even who to ask. Luckily, she had "amazing colleagues and a very supportive community" to help. She decided to break the problem down into "baby steps" that could be solved one at a time.

The first question she had was: "what is DP compliance?" VESA has an elaborate test procedure with an exhaustive set of tests to ensure that a DP driver is compliant with the specification. That is the test suite that was targeted.

One of the first steps she took was to understand what happens when a monitor is connected to a PC or other DP source. Connecting the cable causes the monitor to send a hotplug detect signal to the source. The source then reads the DP configuration data (DPCD) from the monitor to determine the DP capabilities supported by the device. At that point, the source and the monitor (also known as the DP sink) negotiate on the parameters to be used, then data can be sent.

Another thing she needed to understand is DP link training, which is what happens after the hotplug detect signal is received. The source will know about the maximum number of lanes and the maximum link rate supported by the cable, but it will need to determine the quality of the channels between source and sink. The source uses known training patterns to determine the link rate and how many lanes can be supported. Once the channels have been characterized, the link training is done and the two devices are able to exchange data.

She also needed to determine how to actually test for compliance. Her team chose a third-party device, the DPR-120, that has been certified by VESA to execute the compliance test suite. It sits between the source and sink, requesting various tests that display as test patterns on the sink. It compares the patterns to its reference patterns to determine whether the test passes or fails.

Next up was figuring which pieces of hardware and code were responsible for DP compliance. At the lowest layer is the GPU, above that is the i915 driver, which is controlled by the direct rendering manager (DRM) subsystem in the kernel. That exposes an API to user-space components so that programs can send their graphics requests to the hardware. All of those pieces are involved in DP compliance and must be considered in the process.

Mode setting is the process of setting up the scanout buffers, CRTC ("cathode ray tube controller", which is a historical name), and encoders to send the proper display information to the connectors, thus to the sink. That is the responsibility of the kernel. Over the last few years, though, atomic mode setting has been added to make those changes in a single operation in order to prevent partial updates, which can result in display glitches.

When user space requests a set of properties for the display device, atomic mode setting will build the corresponding DRM objects internally and validate them based on its knowledge of the hardware. If the atomic_check() validation step passes, then the atomic_commit() can be done to actually update the hardware with the new configuration. Inherent in that model is the idea that atomic_commit() cannot fail if the check passes, she said.

Handling link failure

When she reached that level of understanding, she believed that atomic mode setting would just make things work and that DP compliance was simply a matter of running the tests. But that turned out not to be the case; some of the compliance tests failed. The problem is that the driver has to do the link training after the commit; if the link training fails at that point, it results in a black screen.

What needs to happen when there is a link failure is for the display pipeline to be set up again with different parameters, but that can't happen until user space requests a new mode. The fix was for the kernel to reduce its saved information about the maximum values for link rate or number of lanes and to send an event to user space informing it of the link training failure. User space can then request a new mode, which results in a new atomic mode setting operation; if it succeeds, the mode set is complete, if it fails, the kernel falls back again and sends another event. That may result in a lower resolution display, but it does not result in the dreaded black screen.

Some lessons were learned in the process; "failure is always an option", she said. The atomic_check() guarantees that the requested mode is possible for the GPU parameters, but cannot guarantee the DP cable and link. Failure of the link can also occur asynchronously; a previously working link can fail due to electrical properties of the connection. It is also possible to do a non-blocking commit, where the mode set returns to user space before the commit has been completed, so there needs to be a way to alert user space to these kinds of problems. Being able to handle asynchronous link failures is an important component of the solution.

There was a bit of a chicken-and-egg problem once the kernel solution was found, though. She made changes to the graphics driver, but without changes to the X server, the tests still would not pass. And an updated X server running on a kernel without the changes would also fail. It required coordinated changes in both to get to a point where the DP compliance could be tested.

Going forward, Intel wants to ensure that any patches made to the driver do not result in regressions to the DP compliance, Navare said. To that end, she has added a DP compliance tool to the IGT test suite that will handle the link failures and request a new mode setting. That way, the DPR-120 can be used to test changes to the graphics driver to catch regressions.

For the future, the plan is to move away from the DPR-120 and to instead use Google's open hardware Chamelium board for display testing. That will allow testing more connector types than just DP—HDMI for example. In order to use it, the DP compliance test suite needs to be ported to the Chamelium and the IGT DP compliance tool will need to be added to the Chamelium testing tool. With that in place, DP compliance testing could be added to the pre-merge continuous-integration tests that Intel is running for its graphics stack.

The whole process "definitely felt like a journey of a thousand miles", she said. There was an enormous amount to learn and it took a fair bit of time to get there. She started working on it at the beginning of 2016 and got the kernel patches merged into 4.12 in mid-2017. She was hesitant at first to post her patches to the mailing list, but learned that doing so was a great way to get good feedback on what she was trying to do. The community was helpful and the feedback was always constructive, she said.

There was some discussion in the Q&A about whether link training could be done at hotplug time so that the X server or other user-space components would not need to handle link failures. It was something that was tried along the way, Navare said, but it can't really work for a number of reasons. In addition, there is always the possibility of a link failure after the mode set call has returned to user space, so the link-failure event handling is still needed.

Interested readers may wish to view the YouTube video of the talk or check out Navare's slides [PDF].

[I would like to thank the X.Org Foundation and the Linux Foundation for travel assistance to Mountain View for XDC.]