Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b68478a8
On Fri, Jul 19, 2013 at 12:57 PM, Daniel Vetter
wrote:
> Atm the crtc helper implementation of set_config has really
> inconsisten semantics: If just an fb update is good enough, dpms state
> will be left as-is, but if we do a full modeset we force everything to
> dpms on.
>
> This change has alr
On Fri, Jul 19, 2013 at 12:57 PM, Daniel Vetter wrote:
> Atm the crtc helper implementation of set_config has really
> inconsisten semantics: If just an fb update is good enough, dpms state
> will be left as-is, but if we do a full modeset we force everything to
> dpms on.
>
> This change has alre
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b68478a8
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b68478a8
Atm the crtc helper implementation of set_config has really
inconsisten semantics: If just an fb update is good enough, dpms state
will be left as-is, but if we do a full modeset we force everything to
dpms on.
This change has already been applied to the i915 modeset code in
commit e3de42b68478a8
