On Fri, Dec 4, 2009 at 6:50 PM, Luc Verhaegen <l...@skynet.be> wrote: > On Fri, Dec 04, 2009 at 06:14:24PM -0500, Alex Deucher wrote: >> On Fri, Dec 4, 2009 at 5:58 PM, Luc Verhaegen <l...@skynet.be> wrote: >> > On Fri, Dec 04, 2009 at 05:18:21PM -0500, Alex Deucher wrote: >> >> This set of patches adds interrupt driven HPD (Hot Plug Detect) >> >> support to r1xx-r7xx radeons. Assuming the HPD pin is wired up >> >> correctly, the driver will generate uevents for digital monitor >> >> connect and disconnect and will retrain DP monitors automatically. >> >> The pin sense functionality can also be used to differentiate between >> >> multiple monitors connected to the same encoder or sharing a ddc line, >> >> however, that has not been hooked up yet. >> >> >> >> Alex >> > >> > Wasn't HPD evil for some reason a few years back? I remember you, >> > bridgie and davey throwing tons of crap at radeonhd for using HPD, and >> > here you are hooking it up to the same r5xx hardware, even though you >> > seem to prefer to name the hooks rs600. >> > >> > What is so different now then? >> >> Nothing is different. You wanted to use them directly for monitor >> detection, but prior to r6xx, they shouldn't be used as the sole means >> of detecting if a monitor is connected or not since they were not >> always wired up properly by the oems. That's why radeonhd won't fail >> to start up for some people and then you'd make them run conntest and >> sort out the hpd routing. As I said back then, you shouldn't use the >> hpd pins directly for detection on pre-r6xx cards. The drm doesn't >> use them directly for monitor detection, it still uses the edid, as I >> advised you back then. The drm uses them to generate interrupts on >> hpd connect/disconnect events. The drm then issues a uevent that >> userspace can listen for and act on. Other than displayport (which is >> r6xx+ only), it doesn't matter if the hpd routing is correct or not >> since all we use it for is to generate an interrupt that something has >> changed. Userspace can then use the event to probe the connectors, or >> whatever. >> >> Alex > > HPD was not tested for one reason and one reason only, no information on > this DDWG required feature was made available by the relevant atombios > tables. > > Add a lack of load detection (because monitors are not required to > provide load on the lines, or because the output simply didn't implement > detection for it (LVTMA)), and that ddc isn't always reliable either > (not all monitors use the 5V the connector provides to still provide > DDC), and that both of those are much more involved and timeconsuming, > then it should be clear that HPD, when available, is massively important > information. Even on r500 it is vastly more reliable than the other > means.
I agree that HPD is a useful and elegant solution and in a perfect world, r5xx cards would have reliable HPD to connector routing information in the bios for the use case you want, but they don't. My point then and now is that the HPD routing information on r5xx cards is unreliable, and as such should not be used directly for monitor detection. Like it or not, edid is a better solution. We did not use HPD routing information directly on r5xx (only via interrupts), so it didn't matter whether the lines were swapped or not in the bios tables. As to the time it takes, monitor probing is not a performance critical path. Most people don't change their monitors that often. Plus, if you do edid probing asynchronously via interrupts, it's even less of an issue. Users can change monitors and the driver will probe the edid in the background before they have even opened the the screen res tool. > > Now, the hardware implements it, atombios ignores it, but HPD > correctness was actually not that bad. > > There are 14 entries in the quirks table where either the hpd lines get > swapped compared to the default (8) or are disabled (6, although i guess > that some of these could've gotten swapped too) for r500. While i do not > pretend that this is a complete and definitive result; when you compare > that with how long the r5xx was sold commercially and how many vastly > different boards were made; then that's pretty bloody good default. > 14 quirks reported and fixed from the number of people who have used radeonhd. I think that's more quirks for a single issue than anything else. How many people tried radeonhd, had it fail, and then ended up using vesa/fglrx/radeon/windows instead and never reported the problem? How many cards have never even been tested? Making the standard behavior something that is known to be unreliable and requiring users to report the issue and run a test and patch the driver to get working results is not good default behavior regardless of how elegant the solution is. *That* was my point. > And guess what, connector info for newer cards, even though their > atombios tables did list HPD pins, and everything was supposed to be > tested soo well, is not always correct either. Exactly. It would be nice it if was, but it's not. Cards will always have quirks. That's why I recommended you check the edid rather than using HPD on cards where the information is known to be unreliable the way you are using it. On r6xx, the HPD routing information is generally reliable so it could be used, although I would still argue that edid is the most reliable method. > > But as long as you stick to your case religiously, then we are certain > that all that crap was thrown justifiedly, even though connection > detection always had to be some algorithm combining all available > information, an algorithm that at most takes up a hundred or so lines. > > On the other hand, a hundred lines or so is a lot when an r500 was > going to be implemented in 1000-1500 lines originally. These patches do not use HPD the same way radeonhd does. I recommended at the time, and still do, that you not rely on information known to be unreliable for monitor detection regardless of how elegant the solution is. The drm does not rely on the HPD routing information for monitor detection. The HPD information is used, as I have always recommended, via interrupts as a hint that the connected devices have changed. In this use case, it doesn't matter if the HPD lines are reversed or not. They let you know that something happened and then you can then deal with it properly. Alex ------------------------------------------------------------------------------ Join us December 9, 2009 for the Red Hat Virtual Experience, a free event focused on virtualization and cloud computing. Attend in-depth sessions from your desk. Your couch. Anywhere. http://p.sf.net/sfu/redhat-sfdev2dev -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
