Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Terminating scrcpy when screen is off (normally via POWER) would turn it on with all-black display #1667

Open
2 tasks done
automatata opened this issue Aug 12, 2020 · 12 comments

Comments

@automatata
Copy link

  • I have read the FAQ.
  • I have searched in existing issues.

Environment

  • OS: Windows
  • scrcpy version: 1.15, 1.15.1, 1.16
  • installation method: Windows release
  • device model: A: OnePlus 6, B: LeEco Max 2
  • Android version: A: 9 and B: 7.1

Describe the bug
A clear and concise description of what the bug is.

I launched scrcpy with no options except -s SERIAL, then turned off the phone screen via each of the following ways:

  • the physical POWER button,
  • the MOD + P shortcut. or
  • executing adb -s SERIAL shell input keyevent POWER.

Specifically I didn't supply --turn-screen-off, -S, or press MOD + o. I terminated scrcpy while the screen is off, either by closing the window or pressing ^C in the terminal.

As a result, Phone B turned on with an all-black display, visible due to the backlight. For phone A, it was impossible to tell wherever the screen turned on just by looking, due to the AMOLED (or so) panel. However its 'wake on screen touch' feature was not working which is a clue phone A wasn't in its screen-off state normally.

Both phones resumed normal after say another physical POWER press or scrcpy connection. Terminating scrcpy before turning off the screens produces no issues. V1.14 never had this issue.

I checked #1653 but it seems my case is not totally the same.

Extract of logcat from phone B on v1.16 (please tell me if more complete log is needed):
https://gist.github.com/automatata/b36a1ff2614125ad8d3f1e73c62d3f53

@rom1v
Copy link
Collaborator

rom1v commented Aug 12, 2020

Thank you for the report with precise and relevant information 👍 (I wish all bug reports were like this one 😉)

The root cause of the problem is that some devices (including yours) handle the restoration of the "power mode" to NORMAL incorrectly: #175 (comment) | 8c8649c

Specifically, in your logs:

08-13 01:49:31.120   547   547 D SurfaceFlinger: Set power mode=2, type=0 flinger=0x7f7e648000
08-13 01:49:31.120   547   547 I SDM     : HWCDisplay::SetPowerMode: display = 0, mode = 2
08-13 01:49:31.120   547   547 I SDM     : DisplayBase::SetDisplayState: Set state = 1, display 0

Scrcpy requests to set the power mode to 2 (NORMAL), but the device internally requests to set it to 1 (DOZE) instead (power modes)

In v1.14, I still decided to reactivate this feature via Ctrl+Shift+o, because on many devices it works without problems (and it's convenient): dcde578
But only users using this shortcut were concerned.

In v1.15, #1576 always restored power state mode to NORMAL on exit: if it was already NORMAL, it should have no effect. But as a consequence, the devices with buggy power state mode handling are now always affected 😕

So I see two possibilities:

  • either disable this behavior by default, and add an option --restore-power-mode-on-exit to enable it
  • either keep this behavior by default, and add an option --do-not-restore-power-mode-on-exit (with a better name)

What do you think?

cc @brunoais @npes87184

@npes87184
Copy link
Contributor

Is it possible to detect this situation automatically? If we can detect it without actually sending command, we can use correct behavior on each device and reduce issues like this.

@rom1v
Copy link
Collaborator

rom1v commented Aug 12, 2020

Is it possible to detect this situation automatically?

I think it is not possible. There is not even a function to get the current power mode.

@npes87184
Copy link
Contributor

Is it possible to detect this situation automatically?

I think it is not possible. There is not even a function to get the current power mode.

Ok, if we cannnot detect it, I vote to keep this behavior by default, and add an option --do-not-restore-power-mode-on-exit (with a better name).

Because most of user will benefit on restoring power state.

@automatata
Copy link
Author

automatata commented Aug 13, 2020

Oh you guys may want to know both phones A and B run those custom ROMs packed with a load of features. I just tried with another very old phone running a more 'pure' CyanogenMod ROM, and it worked fine. I don't know if there's any correlation between the ROM 'purity' and the chance it mishandle the said power state. See what do you think most devices would behave.

For me, either --restore-power-mode-on-exit or --do-not-restore-power-mode-on-exit as default would be fine. I just add into my launch script/shortcut. The cost is that the documentation has to mention this issue, which is one more point for the users to read, so they won't end up unknowingly leaving their screens on, draining battery. But sometimes things like this can't be evaded maybe.

Thank you every developer for your wonderful work!

@brunoais
Copy link
Contributor

brunoais commented Aug 13, 2020

Even though we don't have access to API to tell if the screen is off, we have access to API on whether the phone is sleeping. But even so, we may not need it.

I can't reproduce, so:
As a first step to try figuring out the problem and fixing it please try the version at branch Bug/1667/ClosingScrcpyDoesNotWakeUp also available at PR #1670

@kajdo
Copy link

kajdo commented Apr 1, 2021

I face the same issue and would also love to see the addon parameter --do-not-restore-power-mode-on-exit being implemented for us "unluky ones"

so everybody who isn't affected doesn't have to do anything .... those of us who are will provide the addon flag and we're good to go

to add my phone to the "affect-list" --> oneplus 5t stock rom on android 10 (OxygenOS-Version 10.0.1)

thx for the scrcpy tool - love it :)

@rom1v
Copy link
Collaborator

rom1v commented Apr 1, 2021

Which version do you use?

On latest release, #1670 is included, so it might fix some problems.
On dev branch, there is an additional --power-off-on-close (#824).

@kajdo
Copy link

kajdo commented Apr 1, 2021

Which version do you use?

On latest release, #1670 is included, so it might fix some problems.
On dev branch, there is an additional --power-off-on-close (#824).

jep - just saw it .... running pop 20.10 - so ubuntu repos .... there is good and bad in running ubuntu based distros :)

thx for your reply -- will think about how to move on from there
a) reboot on every disconnect -- and wait until pop update to 21.04 is out
b) build from source
c) install from snap

all options except 3 are fine with me :) .... hope it works with the new version ... will check for open issues or create one if it doesn't

once again - great tool ... very well done @rom1v 👏

@rom1v
Copy link
Collaborator

rom1v commented Apr 1, 2021

b) build from source

Now that's very easy: https://github.com/Genymobile/scrcpy/blob/master/BUILD.md#simple

@kajdo
Copy link

kajdo commented Apr 1, 2021

perfect thx 👍

@rdp
Copy link

rdp commented Oct 12, 2022

--power-off-on-close is a slightly confusing to me, since it doesn't turn off the device, just the screen? I was looking for something to power off the device FWIW...which I think this doesn't, peace!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants