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

CRITICAL: Could not lock mutex #608

Closed
ghost opened this issue Jun 20, 2019 · 1 comment
Closed

CRITICAL: Could not lock mutex #608

ghost opened this issue Jun 20, 2019 · 1 comment
Labels

Comments

@ghost
Copy link

ghost commented Jun 20, 2019

Hey! Love the software!
I've only had one teensy problem since I've started using scrcpy.

Using the arguments:
-S
-n
--render-expired-frames

at the same time causes a critical error "CRITICAL: Could not lock mutex"

If I remove any of the above arguments, it works fine, but it is impossible to use all three in tandem.

Thanks for making my life easy with this software!

@rom1v rom1v added the bug label Jun 20, 2019
rom1v added a commit that referenced this issue Jun 20, 2019
If --no-control is set, then the controller is not initialized (both in
the client and the server), so it is not possible to control the device
to turn its screen off.

See <#608>.
@rom1v
Copy link
Collaborator

rom1v commented Jun 20, 2019

Thank you for your report.

I think it only occurs with -S and -n (not --render-expired-frames).

The problem is that --no-control means "do not control the device at all" (see acc4dcd). So the controller is not even started (both on the client and the server).

For now, I fixed the crash bfb3f08.

Maybe we need some mode "do not control the device except to power it on on start and turn screen off", but I'm not sure…

@rom1v rom1v closed this as completed Jun 22, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant