Open Ruinland opened 1 month ago
Hi @enh-google and all,
After the Android SIG meeting last week, I tried to construct a clean sync of the latest tip-of-tree.
Yet I still have a weird wrong color with guest_swiftshader on the VNC client:
With some testing, I suspect there is a color plate issue or some sort. The color shift pattern looks like : blue-> green, green -> blue, blue->red.
My command line is : "launch_cvd -cpus=4 --memory_mb=8192 --resume=false --gpu_mode="guest_swiftshader" --console=true --start_webrtc=true"
However, by using tools piping surfaceflinger directly, such as scrcpy / screenrecord --output-format=h264 -) the output is correct:
scrcpy
screenrecord --output-format=h264 -
With a whim, I tried to switch the QEMU to my fresh build from QEMU upstream main. The problem remains.
So, to sum up, there seems to be something wrong which resides between the QEMU vnc output buffer and the layers beyond VNC.
Is there anyone encountering the same problem ?
Hi @enh-google and all,
After the Android SIG meeting last week, I tried to construct a clean sync of the latest tip-of-tree.
Yet I still have a weird wrong color with guest_swiftshader on the VNC client:
With some testing, I suspect there is a color plate issue or some sort. The color shift pattern looks like : blue-> green, green -> blue, blue->red.
My command line is : "launch_cvd -cpus=4 --memory_mb=8192 --resume=false --gpu_mode="guest_swiftshader" --console=true --start_webrtc=true"
However, by using tools piping surfaceflinger directly, such as
scrcpy/screenrecord --output-format=h264 -) the output is correct:With a whim, I tried to switch the QEMU to my fresh build from QEMU upstream main. The problem remains.
So, to sum up, there seems to be something wrong which resides between the QEMU vnc output buffer and the layers beyond VNC.
Is there anyone encountering the same problem ?