On Fri, 1 Jul 2011 16:59:48 -0700, Jesse Barnes <[email protected]> wrote:
> That depends on what behavior we want. With the previous fixes, if you > unplug, we'll get a hotplug event, fail to detect a link, and tear down > the receiver. With the old code you'd get bad behavior unless you had > hit a DPMS path earlier. Yeah, the old code was clearly wrong; this looks like something that needs fixing, I just don't know what the right fix is. > A subsequent hotplug will be ignored as far as link training goes, since > we don't have a receiver configured. Do we need separate variables for 'should be configured' and 'actually is configured' then? We need to know if there is a configuration we should be selecting, and then we need to know whether the display is actually using that configuration. > In both cases, we'll emit hotplug events to userspace, which is free to > react (or not) however it wants. Let's assume (for now) that user space doesn't do anything. That seems like a good first step to get right; we should assume that if user space sets some mode then it should work correctly. > So I think we'd need to leave the receiver_configured bit set even if > the hot plug re-train failed, and just try it again on the next hot > plug (assuming we want to preserve user configs across hot plug > events and not just let userspace handle the hotplug events). I don't think we want to lose the user config -- in the absence of any user-driven changes, we want to reset the mode exactly as it was when the monitor is plugged back in. -- [email protected]
pgpY4v9XEWojr.pgp
Description: PGP signature
_______________________________________________ Intel-gfx mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/intel-gfx
