Unable to create window on sway desktop environment and crashes #4760
Comments
|
Looks similar to #3874. In scrcpy, the window is created with a 0-sized hidden window, then it is resized when the first frame is received. Some SDL backends might not handle this correctly I guess. Could you please add this log and retry, to see the actual size it uses: diff --git a/app/src/screen.c b/app/src/screen.c
index 091001bcb..b3593950d 100644
--- a/app/src/screen.c
+++ b/app/src/screen.c
@@ -477,6 +477,9 @@ sc_screen_show_initial_window(struct sc_screen *screen) {
get_initial_optimal_size(screen->content_size, screen->req.width,
screen->req.height);
+ LOGI("Set initial window size: %" PRIu16 "x%" PRIu16,
+ window_size.width, window_size.height);
+
set_window_size(screen, window_size);
SDL_SetWindowPosition(screen->window, x, y);
Also, does it work better if you pass an explicit size (just as a workaround): |
|
I'm sorry, I'm using a package built from the AUR, so it seems I can't modify files, but I've tried the following: scrcpy --window-width=1080 --window-height=1920 -VdebugSway crashed, Sway error log: If I add ❯ scrcpy --window-width=1080 --window-height=1920 -Vdebug
scrcpy 2.4 <https://github.com/Genymobile/scrcpy>
INFO: ADB device found:
INFO: --> (usb) 653c0cb3 device 2210132G
DEBUG: Device serial: 653c0cb3
DEBUG: Using server: /usr/share/scrcpy/scrcpy-server
/usr/share/scrcpy/scrcpy-server: 1 file pushed, 0 skipped. 72.0 MB/s (69007 bytes in 0.001s)
[server] INFO: Device: [Xiaomi] Xiaomi 2210132G (Android 14)
DEBUG: Server connected
DEBUG: Starting controller thread
DEBUG: Starting receiver thread
[server] DEBUG: Using video encoder: 'c2.qti.avc.encoder'
[server] DEBUG: Using audio encoder: 'c2.android.opus.encoder'
INFO: Renderer: opengl
INFO: OpenGL version: 4.6 (Compatibility Profile) Mesa 24.0.3-arch1.1
INFO: Trilinear filtering enabled
DEBUG: Using icon: /usr/share/icons/hicolor/256x256/apps/scrcpy.png
DEBUG: Demuxer 'video': starting thread
DEBUG: Demuxer 'audio': starting thread
INFO: Texture: 1080x2400
[server] DEBUG: Display: using SurfaceControl API
wp_viewport@35: error 2: source rectangle out of buffer bounds
DEBUG: User requested to quit
DEBUG: quit...
DEBUG: Receiver stopped
DEBUG: Demuxer 'audio': end of frames
DEBUG: Demuxer 'video': end of frames
[server] DEBUG: Controller stopped
[server] DEBUG: Device message sender stopped
[server] DEBUG: Screen streaming stopped
[server] DEBUG: Audio encoder stopped
DEBUG: Server disconnected
DEBUG: Server terminatedI also discovered an interesting issue: If I start a sway within sway and run scrcpy in this child sway, it runs normally. (maybe because it is showing on a virtual display?) |
|
I applied the patch and completed the recompilation, but the problem persists. |
|
I made the following changes to the code. Currently it can run normally with parameters, but it will still crash without parameters.
|
|
Could you please also report to SDL? They might know better what should be done. |
|
It seems that there's no way to detect if it's running under a tiling window manager. I attempted to use the characteristic that a tiling window manager would forcibly change the window size to judge during initialization and resizing whether the command took effect, thereby determining the type of window manager. Unfortunately, it appears that changes in size are invisible to SDL. I tried to obtain the size during initialization and resizing, but the behavior is the same on both tiling (like sway) and non-tiling (like KDE) window managers. (When initializing with 0x0, I get 1x1, and during resize, the set and obtained values are the same). It looks like there's no better solution at the moment. If adding a startup parameter is too complicated, it seems that adding an environment variable SCRCPY_TILING_WM could be a simpler solution to the problem.
I will ask in the SDL project to see if there's a better way to address this. |
|
According to feedback, SDL seems unable to resize windows under Wayland, which also explains why applications display only a thin line under KDE wayland. The best solution would be for SDL to return an error message in this case, and for scrcpy to handle the error. However, the most easy method seems to be for scrcpy to check if the SDL_VIDEODRIVER environment variable is set to Wayland, and if so, initialize the window with the parameters passed by the user|0 and then not perform any resizing. This avoids adding a new calling parameter. If you think it's feasible, I'll submit a PR later. |
|
Possibly related SDL issue: libsdl-org/SDL#9283 |
|
For my laptop at least, this issue is resolved. I believe it can be closed if someone else can confirm it. |
|
I found this thread from another post. I'm having the same issue (Fedora 40, KDE w/ Wayland). Can anyone suggest the fix? Thanks! |
Environment
Describe the bug
On Sway (Wayland) desktop environment, when I try to run scrcpy, a window flashes on the screen and then immediately disappears. I attempted to limit the window resolution with
--max-size=1080, and also tried to set windows withtitle=scrcpyandtitle=GM1910to floating mode, but these attempts were unsuccessful.In KDE Plasma environment, scrcpy displays as a very thin line (approximately 100x2 pixels) on the desktop. I can see the screen casting content only when I try to stretch this thin line.
The text was updated successfully, but these errors were encountered: