On Sat, Dec 5, 2009 at 3:33 PM, Luc Verhaegen <l...@skynet.be> wrote: > On Sat, Dec 05, 2009 at 12:06:56AM -0500, Alex Deucher wrote: >> >> > >> > 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 > > I just realized something, the parallel with EDID versus monitor > database (bug #5386) from a few years back is quite great here: > > * EDID is often broken, so we should always use a monitor database. > * Most of it is good, why not use it, and then work around the broken > ones. > * No, EDID is often broken, we should always use a monitor database. > > Luckily, in that situation, words like "So why don't create and > maintain one then", ended the discussion. Sadly this is not possible > here. > > So. whatever.
/me wonders when he walked into a episode of Glee. I'm nearly sure you aren't the popular cheerleader. Learn to lose an argument like an adult, you don't need to have the last word in every discussion. Like you didn't even try with this post. HTFU. Dave. ------------------------------------------------------------------------------ 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
