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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.