From: Imre Deak <imre.deak@intel.com>
To: Chris Wilson <chris@chris-wilson.co.uk>
Cc: intel-gfx@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915: force full modeset if the connector is in DPMS OFF mode
Date: Fri, 03 May 2013 15:43:52 +0300 [thread overview]
Message-ID: <1367585032.2572.13.camel@intelbox> (raw)
In-Reply-To: <20130503122233.GC21865@cantiga.alporthouse.com>
On Fri, 2013-05-03 at 13:22 +0100, Chris Wilson wrote:
> On Fri, May 03, 2013 at 02:55:45PM +0300, Imre Deak wrote:
> > On Fri, 2013-05-03 at 12:44 +0100, Chris Wilson wrote:
> > > On Fri, May 03, 2013 at 02:22:09PM +0300, Imre Deak wrote:
> > > > Currently the driver's assumed behavior for a modeset with an attached
> > > > FB is that the corresponding connector will be switched to DPMS ON mode
> > > > if it happened to be in DPMS OFF (or another power save mode). This
> > > > wasn't enforced though if only the FB changed, everything else (format,
> > > > connector etc.) remaining the same. In this case we only set the new FB
> > > > base and left the connector in the old power save mode.
> > > >
> > > > Fix this by forcing a full modeset whenever there is an attached FB and
> > > > any affected connector is in a power save mode.
> > > >
> > > > Signed-off-by: Imre Deak <imre.deak@intel.com>
> > >
> > > NAK. Papering over bugs, much?
> >
> > Ok. I posted this based on our IRC discussion where we seemed to agree
> > that DPMS_ON is assumed already; just that it's not done consistently.
> > That is if user space does a modeset now that ends up in a full modeset
> > (lets say a new FB with different format) then the kernel will do a
> > DPMS_ON. But if the new FB happens to be the same format then it won't.
> > I thought this is inconsistent and should be fixed.
> >
> > Another way to make it consistent would be then to remove DPMS ON from
> > the full modeset path..
>
> Right, we have mentioned in the past that the conflation between DPMS
> and modesetting is a more recent bug that is going to cause us even more
> trouble later. I am not sure how we can fix that as UXA already makes
> many bad assumptions.
Ok, so I assume the right approach for user space is to do an explicit
DPMS_ON after modesetting.
--Imre
next prev parent reply other threads:[~2013-05-03 12:43 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-03 11:22 [PATCH] drm/i915: force full modeset if the connector is in DPMS OFF mode Imre Deak
2013-05-03 11:27 ` Daniel Vetter
2013-05-03 11:32 ` Daniel Vetter
2013-05-03 11:39 ` Imre Deak
2013-05-03 11:44 ` Chris Wilson
2013-05-03 11:55 ` Imre Deak
2013-05-03 12:22 ` Chris Wilson
2013-05-03 12:43 ` Imre Deak [this message]
2013-05-03 15:55 ` Daniel Vetter
2013-05-03 16:22 ` Jesse Barnes
2013-05-03 16:28 ` Chris Wilson
2013-05-03 16:50 ` Daniel Vetter
2013-05-08 19:02 ` Daniel Vetter
2013-05-03 11:51 ` Jani Nikula
2013-05-03 17:40 ` Egbert Eich
2013-05-03 17:44 ` [PATCH V2] " Egbert Eich
2013-05-20 21:13 ` Jesse Barnes
2013-05-21 16:44 ` Daniel Vetter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1367585032.2572.13.camel@intelbox \
--to=imre.deak@intel.com \
--cc=chris@chris-wilson.co.uk \
--cc=intel-gfx@lists.freedesktop.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox