On Wed, Aug 17, 2016 at 12:25:40PM +0300, David Weinehall wrote: > On Wed, Aug 17, 2016 at 09:08:58AM +0100, Chris Wilson wrote: > > On Wed, Aug 17, 2016 at 11:02:32AM +0300, David Weinehall wrote: > > > Since the workaround for buggy displays that do not reply to > > > live status detect immediately affects a rather limited set of > > > displays, and since the price paid (almost 100ms per HDMI-port), > > > we should have that hack disabled by default. > > > > > > Rather than leaving people with these kinds of broken displays > > > out in the cold completely, add a module parameter, defaulting > > > to -1 (live status detection on supported platforms, but without > > > the extra delays), that allows for re-enabling this hack. > > > > No. It is a regression. We revert back to the previous status quo, > > and then try to introduce live-status checking in a way that works if at > > all possible. > > The way I understand it, the only approaches that would allow for > combining live status checking with buggy displays are: I haven't seen any convincing analysis as to why live-status works better than ddc 0x50. Certainly not in the changelogs. The rule is that even if you fix one system, if you break anything else in the process and you cannot fix it promptly you revert back to the previous state and try again. -Chris -- Chris Wilson, Intel Open Source Technology Centre _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
