Re: [PATCH 2/2] drm/i915: add module param for live_status

[Daniel Vetter <daniel@ffwll.ch>]

On Wed, Aug 17, 2016 at 10:35:31AM +0100, Chris Wilson wrote:
> 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.

+1, and mine counts a thousands since magic maintainer powers.

We added this to make it hdmi complaint, because vpg asked for it. It
breaks shit, out it goes again. End of discussion.

The linux community is _very_ clear that when a standard disagrees with
experimental reality, reality wins. On top of that I'm very clear that
we're not going to add module parameters to fine-tune things to appease
different people and groups. Either it works, and we enable it, or it
doesn't, and then we should throw it out again. There's some grey area
with big features like fbc/psr where it makes sense to keep the code until
it's fixed, but definitely not for something as small as this here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx