<html>
<head>
<base href="https://bugs.freedesktop.org/">
</head>
<body>
<p>
<div>
<b><a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - [CI][DRMTIP] igt@pm_backlight@* - incomplete - system hang?"
href="https://bugs.freedesktop.org/show_bug.cgi?id=107820#c8">Comment # 8</a>
on <a class="bz_bug_link
bz_status_ASSIGNED "
title="ASSIGNED - [CI][DRMTIP] igt@pm_backlight@* - incomplete - system hang?"
href="https://bugs.freedesktop.org/show_bug.cgi?id=107820">bug 107820</a>
from <span class="vcard"><a class="email" href="mailto:harish.chegondi@intel.com" title="harish.chegondi@intel.com">harish.chegondi@intel.com</a>
</span></b>
<pre>Below are comments from the definition of "struct drm_crtc_state" which explain
what active/inactive crtc states mean. If the CRTC state is inactive it implies
CRTC is not actively displaying in which case it doesn't make sense to turn on
the backlight. CRTC state should be active in order to turn on the backlight.
The comments also imply if the user space turns off the DPMS, it has to be the
user space that should turn on the DPMS and not the kernel.
/**
* @active: Whether the CRTC is actively displaying (used for DPMS).
* Implies that @enable is set. The driver must not release any shared
* resources if @active is set to false but @enable still true, because e
* userspace expects that a DPMS ON always succeeds.
*
* Hence drivers must not consult @active in their various
* &drm_mode_config_funcs.atomic_check callback to reject an atomic
* commit. They can consult it to aid in the computation of derived
* hardware state, since even in the DPMS OFF state the display hardware
* should be as much powered down as when the CRTC is completely
* disabled through setting @enable to false.
*/
bool active;</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the QA Contact for the bug.</li>
<li>You are on the CC list for the bug.</li>
</ul>
</body>
</html>