Prevent system sleep when reading lon pieces of text in say all by LeonarddeR · Pull Request #10643 · nvaccess/nvda

LeonarddeR · 2019-12-19T18:40:28Z

Link to issue number:

Follow up of #10111

Summary of the issue:

When a system is set up to lock or go to sleep within one minute, say all is interrupted when reading long paragraphs in virtual buffers. Possibly in other cases as well.

Description of how this pull request fixes the issue:

Similar as in #10111. We instruct the system not to sleep. This happens on every line we reach.

Testing performed:

Tested with a long paragraph of text in Firefox browse mode. My system no longer locks within one minute.

Known issues with pull request:

In theory, say all could still be interrupted when reading a very long line at a very slow rate.

Change log entry:

Changes
- NVDA prevents the system from locking or going to sleep when in say all.

LeonarddeR · 2020-01-30T12:53:00Z

@feerrenrut: I'd like to shamelessly ask you to review this, as this really interrupts my current work flow in a major way. I have a system that has a lock of the screen enforced at one minute by means of a group policy, and this makes it very hard to use say all in Word and on the web.

feerrenrut

Thanks @LeonarddeR

btman16 · 2020-05-02T20:38:48Z

Hi,

On systems without group policies set, it's preventing my laptop from turning off the screen which is consuming more power on my laptop. My laptop has a very small battery, so I need to get as much power out of it as I can, and this will have negative effects.
This is a huge show stopper for me, and I'd like to ask if this can be made optional please? Or could there be a way to do a say all without this change?

Thank you very much and I look forward to any input you may have.

Thanks,

Brandon

feerrenrut · 2020-05-04T15:49:07Z

@LeonarddeR Did you investigate using only winKernel.SetThreadExecutionState(winKernel.ES_SYSTEM_REQUIRED) E.G. leaving out winKernel.ES_DISPLAY_REQUIRED?

@btman16 It would be best if you create a new issue to explain the problem. In the new issue please answer the following:

Do you expect the computer to sleep, or just let the display turn off and continue with say-all?
Is the screen being kept on even when not using say-all?

LeonarddeR · 2020-05-04T16:02:50Z

This flag was added on request of @michaelDCurran in #10111 (comment) . I"m happy to remove it for this case and provide a pr. Does this block 2020.1 from being released, though?

feerrenrut · 2020-05-04T16:19:42Z

I"m happy to remove it for this case and provide a pr.

I'd like to understand the use-cases from @btman16 better first.

Does this block 2020.1 from being released

I don't think this is a serious enough issue to block the release at this late stage.

From the MS docs:

Multimedia applications, such as video players and presentation applications, must use ES_DISPLAY_REQUIRED when they display video for long periods of time without user input. Applications such as word processors, spreadsheets, browsers, and games do not need to call SetThreadExecutionState.

This makes me think that ES_DISPLAY_REQUIRED isn't appropriate for audio only users, though, of course this depends on the user. Low-vision users may still want the screen to be kept on. It's certainly annoying for me having the screen turn off while I'm trying to read a long thing.

Also the end of the MS docs has an answer to the screen saver question. Though the use of screen savers is pretty rare these days!

This function does not stop the screen saver from executing.

LeonarddeR · 2020-05-04T17:26:01Z

@btman16 Would you be able to try this build of NVDA to see whether this fixes it for you?

LeonarddeR · 2020-05-04T17:29:29Z

Low-vision users may still want the screen to be kept on. It's certainly annoying for me having the screen turn off while I'm trying to read a long thing.

That's what I figured as well. Especially if we intend the NVDA highlighter to follow along say all at some point.

@btman16 nevertheless, it would be helpful to see how the try build behaves in your case. Also, wouldn't it be possible for you to disable your screen with windows+p entirely (choose second screen)? That works for several older pc's that still have a dedicated VGA connector, like my five year old laptop.

btman16 · 2020-05-04T18:58:29Z

Hi, Fixed! Thanks so much! I think this will be perfect! Thanks, Brandon

…

On 5/4/20, Leonard de Ruijter ***@***.***> wrote: > > > > I"m happy to remove it for this case and provide a pr. > > I'd like to understand the use-cases from @btman16 better first. > > > Does this block 2020.1 from being released > > I don't think this is a serious enough issue to block the release at this > late stage. > > From the [MS > docs](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadexecutionstate): > > > Multimedia applications, such as video players and presentation > > applications, must use ES_DISPLAY_REQUIRED when they display video for > > long periods of time without user input. Applications such as word > > processors, spreadsheets, browsers, and games do not need to call > > SetThreadExecutionState. > > This makes me think that `ES_DISPLAY_REQUIRED` isn't appropriate for audio > only users, though, > Low-vision users may still want the screen to be > kept on. It's certainly annoying for me having the screen turn off while > I'm trying to read a long thing. That's what I figured as well. Especially if we intend the NVDA highlighter to follow along say all at some point. @btman16 nevertheless, it would be helpful to see how the try build behaves in your case. Also, wouldn't it be possible for you to disable your screen with windows+p entirely (choose second screen)? That works for several older pc's that still have a dedicated VGA connector, like my five year old laptop. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #10643 (comment)

-- “Be what you are. This is the first step towards becoming better than you are.” – J. C. Hare & A. W. Hare

btman16 · 2020-05-04T18:59:37Z

Hi, Another question is, since this Try build seemed to fix it, do I still need to make a new issue? Thanks, Brandon

…

On 5/4/20, Brandon Tyson ***@***.***> wrote: Hi, Fixed! Thanks so much! I think this will be perfect! Thanks, Brandon On 5/4/20, Leonard de Ruijter ***@***.***> wrote: >> >> >> > I"m happy to remove it for this case and provide a pr. >> >> I'd like to understand the use-cases from @btman16 better first. >> >> > Does this block 2020.1 from being released >> >> I don't think this is a serious enough issue to block the release at >> this >> late stage. >> >> From the [MS >> docs](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadexecutionstate): >> >> > Multimedia applications, such as video players and presentation >> > applications, must use ES_DISPLAY_REQUIRED when they display video for >> > long periods of time without user input. Applications such as word >> > processors, spreadsheets, browsers, and games do not need to call >> > SetThreadExecutionState. >> >> This makes me think that `ES_DISPLAY_REQUIRED` isn't appropriate for >> audio >> only users, though, > Low-vision users may still want the screen to be >> kept on. It's certainly annoying for me having the screen turn off while >> I'm trying to read a long thing. > > That's what I figured as well. Especially if we intend the NVDA > highlighter > to follow along say all at some point. > > @btman16 nevertheless, it would be helpful to see how the try build > behaves > in your case. Also, wouldn't it be possible for you to disable your > screen > with windows+p entirely (choose second screen)? That works for several > older > pc's that still have a dedicated VGA connector, like my five year old > laptop. > > -- > You are receiving this because you were mentioned. > Reply to this email directly or view it on GitHub: > #10643 (comment) -- “Be what you are. This is the first step towards becoming better than you are.” – J. C. Hare & A. W. Hare

-- “Be what you are. This is the first step towards becoming better than you are.” – J. C. Hare & A. W. Hare

josephsl · 2020-05-04T19:03:43Z

Hi, no. As for releasing as part of 2020.1, I’m personally against it due to risk of regressions in areas such as power usage, so I propose letting it bake for a while in alpha. Thanks.

btman16 · 2020-05-04T19:07:33Z

Hi, I'm sorry for sending so many messages, I missed your question about using second screen only. On this machine, that strategy won't work since there's no VGA connector. As for the highlighter, that is a good point, and I don't know what we could do in that instance. Is it possible to perhaps do some sort of logic, where if the user had the highlighter enabled, then you could call the IsDisplayRequired, but not call it if the highlighter is turned off? As I said before I totally see where you're coming from, and I think this try build does fix my case. And for you, are you still able to read without an issue if you use the try build? Thanks, Brandon

…

On 5/4/20, Brandon Tyson ***@***.***> wrote: Hi, Another question is, since this Try build seemed to fix it, do I still need to make a new issue? Thanks, Brandon On 5/4/20, Brandon Tyson ***@***.***> wrote: > Hi, > > Fixed! > > Thanks so much! I think this will be perfect! > > Thanks, > > Brandon > > On 5/4/20, Leonard de Ruijter ***@***.***> wrote: >>> >>> >>> > I"m happy to remove it for this case and provide a pr. >>> >>> I'd like to understand the use-cases from @btman16 better first. >>> >>> > Does this block 2020.1 from being released >>> >>> I don't think this is a serious enough issue to block the release at >>> this >>> late stage. >>> >>> From the [MS >>> docs](https://docs.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-setthreadexecutionstate): >>> >>> > Multimedia applications, such as video players and presentation >>> > applications, must use ES_DISPLAY_REQUIRED when they display video >>> > for >>> > long periods of time without user input. Applications such as word >>> > processors, spreadsheets, browsers, and games do not need to call >>> > SetThreadExecutionState. >>> >>> This makes me think that `ES_DISPLAY_REQUIRED` isn't appropriate for >>> audio >>> only users, though, > Low-vision users may still want the screen to be >>> kept on. It's certainly annoying for me having the screen turn off >>> while >>> I'm trying to read a long thing. >> >> That's what I figured as well. Especially if we intend the NVDA >> highlighter >> to follow along say all at some point. >> >> @btman16 nevertheless, it would be helpful to see how the try build >> behaves >> in your case. Also, wouldn't it be possible for you to disable your >> screen >> with windows+p entirely (choose second screen)? That works for several >> older >> pc's that still have a dedicated VGA connector, like my five year old >> laptop. >> >> -- >> You are receiving this because you were mentioned. >> Reply to this email directly or view it on GitHub: >> #10643 (comment) > > > -- > “Be what you are. This is the first step towards becoming better than you > are.” > – J. C. Hare & A. W. Hare > -- “Be what you are. This is the first step towards becoming better than you are.” – J. C. Hare & A. W. Hare

-- “Be what you are. This is the first step towards becoming better than you are.” – J. C. Hare & A. W. Hare

feerrenrut · 2020-05-05T15:57:56Z

While low vision or sighted users likely want to keep their screen on during long periods of reading, I think they are more likely to windows settings appropriate for keeping their screen on, and familiar with using the mouse to keep the screen on.

It's certainly too late 2020.1, but I would accept a PR for this change.

btman16 · 2020-05-05T20:07:19Z

Hi, Thanks for these changes, and your input. Would you still like me to make a new issue describing this case? Thanks, Brandon

…

Sent from my iPhone

On May 5, 2020, at 11:58 AM, Reef Turner ***@***.***> wrote: While low vision or sighted users likely want to keep their screen on during long periods of reading, I think they are more likely to windows settings appropriate for keeping their screen on, and familiar with using the mouse to keep the screen on. It's certainly too late 2020.1, but I would accept a PR for this change. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

XLTechie · 2020-05-06T05:45:44Z

As for the highlighter, that is a good point, and I don't know what we could do in that instance. Is it possible to perhaps do some sort of logic, where if the user had the highlighter enabled, then you could call the IsDisplayRequired, but not call it if the highlighter is turned off?

Perhaps a stupid question since noone has asked it yet, but wouldn't the screen curtain figure into this as well? In other words: if it's on, you would want to let the display keep sleeping, but otherwise keep the machine awake.

btman16 · 2020-05-06T15:33:34Z

Hi, This is a totally separate instance, I think. The reason is that screen curtain related things don't apply at all to Windows 7, so the proposed solution would probably not want to center around screen curtain. Does that answer your question? Thanks, Brandon

…

On 5/6/20, Luke Davis ***@***.***> wrote: > As for the highlighter, that is a good point, and I don't know what we > could do in that instance. Is it possible to perhaps do some sort of > logic, where if the user had the highlighter enabled, then you could > call the IsDisplayRequired, but not call it if the highlighter is > turned off? Perhaps a stupid question since noone has asked it yet, but wouldn't the screen curtain figure into this as well? In other words: if it's on, you would want to let the display keep sleeping, but otherwise keep the machine awake. -- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: #10643 (comment)

-- “Be what you are. This is the first step towards becoming better than you are.” – J. C. Hare & A. W. Hare

XLTechie · 2020-05-06T17:00:27Z

Yes, I had missed the Win 7 affiliation, sorry.

feerrenrut · 2020-05-08T14:46:39Z

Would you still like me to make a new issue describing this case?

@btman16 No new issue required. Thanks!

btman16 · 2020-05-08T16:33:11Z

I would like to thank you all for you help and proposing a solution to the issue. Will it be showing up in Alpha?

feerrenrut · 2020-05-11T10:38:47Z

Will it be showing up in Alpha?

Yes, it was delivered with PR #11118 and should now be available in alpha.

@btman16

Fixes #17649 Partially reverts #11118 Follow up of #10111, #10643, Summary of the issue: On some systems (mine, for example 😉) the screen still locks during a say all even though we reset the system idle timer. We also reset the display timer in the past, but this was reverted in #11118, particularly on request of @btman16 Description of user facing changes Added a new advanced setting that, when enabled, also resets the display timer. Description of development approach Added new helper/wrapper methods to systemUtils Rather than resetting the timer(s) many times during a say all, we now persist the state during say all using the ES_CONTINUOUS flag. This should avoid an edge case where reading a line takes more then a minute and the sleep timer is a minute, in which case the system will still lock.

Avoid screen lock during say all

07f5253

LeonarddeR marked this pull request as ready for review December 20, 2019 08:08

LeonarddeR requested a review from feerrenrut January 30, 2020 12:51

feerrenrut approved these changes Jan 30, 2020

View reviewed changes

feerrenrut merged commit b94442a into nvaccess:master Jan 30, 2020

nvaccessAuto added this to the 2019.3 milestone Jan 30, 2020

feerrenrut modified the milestones: 2019.3, 2020.1 Jan 30, 2020

feerrenrut added a commit that referenced this pull request Jan 30, 2020

Update changes file for PR #10643

cc8e131

LeonarddeR mentioned this pull request May 6, 2020

Allow display to turn off for power saving during say all #11118

Merged

LeonarddeR mentioned this pull request Aug 25, 2020

Revert "Allow display to turn off for power saving during say all" #11524

Closed

lukaszgo1 mentioned this pull request Aug 20, 2022

Add function to prevent screen turning off / laptop going to sleep during say all #14036

Closed

LeonarddeR mentioned this pull request Jan 24, 2025

Ensure screen stays on during say all #17651

Merged

5 tasks

LeonarddeR deleted the avoidLockDuringSayAll branch August 23, 2025 06:27

Uh oh!

Conversation

LeonarddeR commented Dec 19, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Link to issue number:

Summary of the issue:

Description of how this pull request fixes the issue:

Testing performed:

Known issues with pull request:

Change log entry:

Uh oh!

LeonarddeR commented Jan 30, 2020

Uh oh!

feerrenrut left a comment

Choose a reason for hiding this comment

Uh oh!

btman16 commented May 2, 2020

Uh oh!

feerrenrut commented May 4, 2020

Uh oh!

LeonarddeR commented May 4, 2020

Uh oh!

feerrenrut commented May 4, 2020

Uh oh!

LeonarddeR commented May 4, 2020

Uh oh!

LeonarddeR commented May 4, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

btman16 commented May 4, 2020 via email

Uh oh!

btman16 commented May 4, 2020 via email

Uh oh!

josephsl commented May 4, 2020 via email • edited by feerrenrut Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

btman16 commented May 4, 2020 via email

Uh oh!

feerrenrut commented May 5, 2020

Uh oh!

btman16 commented May 5, 2020 via email

Uh oh!

XLTechie commented May 6, 2020 via email

Uh oh!

btman16 commented May 6, 2020 via email

Uh oh!

XLTechie commented May 6, 2020 via email

Uh oh!

feerrenrut commented May 8, 2020

Uh oh!

btman16 commented May 8, 2020 via email • edited by feerrenrut Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

feerrenrut commented May 11, 2020

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

6 participants

LeonarddeR commented Dec 19, 2019 •

edited

Loading

LeonarddeR commented May 4, 2020 •

edited

Loading

josephsl commented May 4, 2020 via email •

edited by feerrenrut

Loading

btman16 commented May 8, 2020 via email •

edited by feerrenrut

Loading