Today, a post on one of my favoritest sites (Hackaday) piqued my interest. The post was titled Connect a Retina display to a regular computer. I have always been a huge fan of high-resolution displays, but they have traditionally been far outside my price range. But here, says the article, is a massively high resolution display, with simple drive characteristics, that can be had for only $55.
I bought some immediately.
The post links to the efforts of [Andrzej] and his post on the subject, http://emerythacks.blogspot.com/2013/04/connecting-ipad-retina-lcd-to-pc.html, and if he should ever happen to run across this page I sincerely thank him for his work in this area. But I am nothing if not a perfectionist, and happen to be an electrical engineer by trade with some high speed design experience, and I have been working on some very similar things at work, so it seems an excellent opportunity to improve upon the original design and make something a little cleaner.
So here’s the plan of attack. While the displays make their way to my house, I will begin the design. The display is a LG LP097QX1-SPA1, for which I have a half-Korean datasheet posted here: LP097QX1-SPA1. (Edit: A somewhat less Korean datasheet for the similar -SPC1: LP097QX1-SPC1) The datasheet outlines the pinout of the display, in the following manner:
Neato! It’s just DisplayPort and power and LED strings. We can deal with this. DisplayPort means no pesky EDID EEPROMS, and no finicky LVDS data format issues. Should be a cakewalk. However it is also worth mentioning that what you see is what you get. There is no capacitive touch interface here. That is all found on the transparent glass digitizer normally attached to the front of this LCD. A lot of people in various forums seem confused on that topic. I purchased a digitizer as well, but I give no guarantees on how far I’ll get on that.
Based on [Andrzej]’s original writeup, I will be emulating his work while adhering to the following additional guidelines:
- I hate splicing wires. I have done plenty of Apple Display Connector to DVI conversions (hint: topic of a future post), and I really hate having to splice itty bitty wires. It’s also a great testament to the hardiness of DVI that the display works with such a simple fix, as the resultant signal looks horrid. I don’t have so much faith in the higher-frequency DisplayPort signals, so I will be designing the solution with a standard mDP connector onboard.
- Driving LCDs with a constant-voltage supply is not ideal. I know it works, but LEDs are constant-current devices and are either hard to drive adequately or easy to overdrive with a constant-voltage supply. I have designed a reference circuit for a six-channel LED driver for a project at work, and will attempt to adapt this to the 12 strings of this display.
- Everything worth doing is worth doing right. If it’s not worth doing right, it’s not worth doing. This is really the most important thing to remember about this and every project. I really hate half-arsing projects, so much so that many of my projects have been put on semi-permanent hold if they fail to live up to the initial elegance expected of them. This mod should provide an elegant, highly usable, production-quality end product, or I just won’t end up using it.
I believe my plans to be reasonably sound, but I do have a few nagging questions remaining, primarily concerning the backlight. In a traditional embedded system, the display controller has control over the backlight state and brightness, and wiggles the controls of the backlight driver to its whims. In a commercial DP monitor, the monitor’s display controller pulls this information from the DP data. But in this application, the DP signal data is simply passed through from input connector to panel, no post-processing included, and no additional backlight controls are presented, so presumably the backlight will be on all the time (which is undesirable). IPS displays are thankfully naturally black, but that’s no real consolation for a system being designed as elegantly as possible. I will need to investigate this issue when the panels arrive. I also need to think through backlight brightness adjustment, because again no backlight level control data is exposed.
Next step is to start blocking out the main components of the interface board. As I have nothing yet to show, I’ll leave that for the next post, so that’s it for now. Thanks for watching!
Maybe you could use Pin 2 HPD (Hot plug detect) to enable/disable the backlight. All that’s left is a micro and two buttons to change the brightness.
I also got excited when I got news of this hack, so I hope you will succeed in turning this into a proper solution.
Unfortunately HPD is an output from the panel (it lets the DP host know it’s ready to receive data). It is certainly a vector for experimentation, but it is unlikely that it changes in response to blanking periods (e.g. resolution changes), which is what I really want.
The greater question is whether the data even exists in the datastream, as the block diagram of the display controller doesn’t seem to indicate. I’ll follow up with a second post in a few hours detailing what needs to be done if the data exists. It is ugly…
Well, what I meant was that you could check for the value of HDP and then turn on/off the backlight accordingly.
I agree that extracting any data at all from the DP stream will be very ugly – to the point where adding a simple switch for the backlight will be more elegant…
From what I understand about the panel and the HPD pin in general, the panel asserts HPD when its internal circuitry is ready to receive commands via the AUX control port. It does this independent of anything currently happening on its data lanes. Assuming the panel is powered from a source which does not depend on the state of the data link (e.g. an internal 3.3V supply), it will assert HPD whether or not the DP host is active, because it has to do this before it can tell whether the host is alive. So (to the best of my current knowledge on the subject), it is not useful to poll HPD to determine whether to enable the backlight, because the panel will have it asserted as long as it has power. I’d be happy to be wrong though..
Hi, i think my backligt is broken but i don’t know for sure. I want to test the lcd backlight but does anyone has an andea how to do this? Which pin should have 3.3v in order to test?
The backlight is a quite simple circuit, just six or seven LEDs in series. The panel electronics do not need to be powered in order for the backlight to light up. That said, you need to provide much more than 3.3V – the forward voltage of this many white LEDs in series is about 20V. You will need to apply 19-20V (preferably through a small resistor, maybe 100 ohms) between pins 45-46 and/or 48-49 (positive) and pins 30-35 and/or 37-42 (negative). Any one combination of those pins – say, (+) pin 46 and (-) pin 39 – should produce a valid result. Even with the rest of the display unpowered, you should be able to see the backlight blink on when power is applied to these pins. There are also openings at the corners or edges of the display where the white diffuser plastic is exposed; this should very clearly light up when the backlight is active.
It would be very unlikely for your entire backlight to be dead, with so many independent parallel circuits – that is, unless you did something very bad to it! (I’d be lying if I said I never accidentally applied 60V to something when I meant to adjust the current knob instead)