Re: [PATCH xserver 1/3] xfree86: Clean up DPMS support

2017-03-24 Thread Eric Anholt
Adam Jackson  writes:

> Rather than setting up a per-screen private, just conditionally
> initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
> that to determine whether DPMS is supported.
>
> We also move the "turn the screen back on at CloseScreen" logic into the
> DPMS extension's (new) reset hook. This would be a behavior change for
> the non-xfree86 servers, if any of them had non-stub DPMS support.

Doesn't this move when the DPMSSet(On) happens in the CloseScreen
sequence for xorg?  Is that going to be OK?

I'm pretty sure the motivation of this call is for UMS drivers to try to
successfully restore back to the console (for KMS, this is the kernel's
job, not ours), but I think UMS drivers should all be doing that already
and the close-time call should probably just be removed instead.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/3] xfree86: Clean up DPMS support

2017-03-24 Thread Adam Jackson
On Fri, 2017-03-24 at 10:34 -0700, Eric Anholt wrote:
> > Adam Jackson  writes:
> 
> > Rather than setting up a per-screen private, just conditionally
> > initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
> > that to determine whether DPMS is supported.
> > 
> > We also move the "turn the screen back on at CloseScreen" logic into the
> > DPMS extension's (new) reset hook. This would be a behavior change for
> > the non-xfree86 servers, if any of them had non-stub DPMS support.
> 
> Doesn't this move when the DPMSSet(On) happens in the CloseScreen
> sequence for xorg?  Is that going to be OK?

It does move it, and I expect it to be okay. It moves the DPMS-on
earlier, because CloseDownExtensions happens way before CloseScreen.
CDE is so close to Dispatch that this should be indistinguishable from
"the last request processed was a DPMS on", and if we can't CloseScreen
in that scenario then we're already in a world of hurt.

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/3] xfree86: Clean up DPMS support

2017-03-24 Thread Eric Anholt
Adam Jackson  writes:

> On Fri, 2017-03-24 at 10:34 -0700, Eric Anholt wrote:
>> > Adam Jackson  writes:
>> 
>> > Rather than setting up a per-screen private, just conditionally
>> > initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
>> > that to determine whether DPMS is supported.
>> > 
>> > We also move the "turn the screen back on at CloseScreen" logic into the
>> > DPMS extension's (new) reset hook. This would be a behavior change for
>> > the non-xfree86 servers, if any of them had non-stub DPMS support.
>> 
>> Doesn't this move when the DPMSSet(On) happens in the CloseScreen
>> sequence for xorg?  Is that going to be OK?
>
> It does move it, and I expect it to be okay. It moves the DPMS-on
> earlier, because CloseDownExtensions happens way before CloseScreen.
> CDE is so close to Dispatch that this should be indistinguishable from
> "the last request processed was a DPMS on", and if we can't CloseScreen
> in that scenario then we're already in a world of hurt.

That's basically what I was looking for.  Thanks.


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/3] xfree86: Clean up DPMS support

2017-03-27 Thread Eric Anholt
Adam Jackson  writes:

> Rather than setting up a per-screen private, just conditionally
> initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
> that to determine whether DPMS is supported.
>
> We also move the "turn the screen back on at CloseScreen" logic into the
> DPMS extension's (new) reset hook. This would be a behavior change for
> the non-xfree86 servers, if any of them had non-stub DPMS support.
>
> Signed-off-by: Adam Jackson 

I took another look today, and this series is:

Reviewed-by: Eric Anholt 


signature.asc
Description: PGP signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 1/3] xfree86: Clean up DPMS support

2017-03-27 Thread Adam Jackson
On Mon, 2017-03-27 at 10:40 -0700, Eric Anholt wrote:
> > Adam Jackson  writes:
> 
> > Rather than setting up a per-screen private, just conditionally
> > initialize ScrnInfoRec::DPMSSet based on the config options, and inspect
> > that to determine whether DPMS is supported.
> > 
> > We also move the "turn the screen back on at CloseScreen" logic into the
> > DPMS extension's (new) reset hook. This would be a behavior change for
> > the non-xfree86 servers, if any of them had non-stub DPMS support.
> > 
> > Signed-off-by: Adam Jackson 
> 
> I took another look today, and this series is:
> 
> Reviewed-by: Eric Anholt 

Merged, thanks:

remote: I: patch #146299 updated using rev 
8ed0b00fceb34cdb54a0ea113c3cdff3b4c9e7e1.
remote: E: failed to find patch for rev 
7f1ef9289d974fc2bacc968ae0b5d7714382cb9e.
remote: I: patch #146300 updated using rev 
33604187674ec78b2c0bf7f67af250acc80cf23a.
remote: I: 2 patch(es) updated to state Accepted.
To ssh://git.freedesktop.org/git/xorg/xserver
   21eda74..3360418  master -> master

- ajax
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel