On Fri, 29 Dec 2017 13:31:50 -0500 nerdopolis <bluescreen_aven...@verizon.net> wrote:
> This attempts to wake up secondary framebuffer devices
> (/dev/fb1 and up) as usually these devices start powered off, and
> the FBIOPUT_VSCREENINFO ioctl turns it on. This was tested on a
> qemu system with the options:
>
> -vga none -device VGA,id=video0 -device secondary-vga,id=video1 \
> -device secondary-vga,id=video2
> ---
> libweston/compositor-fbdev.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/libweston/compositor-fbdev.c b/libweston/compositor-fbdev.c
> index ef571339..39668aa8 100644
> --- a/libweston/compositor-fbdev.c
> +++ b/libweston/compositor-fbdev.c
> @@ -361,6 +361,13 @@ fbdev_frame_buffer_open(const char *fb_dev,
> return -1;
> }
>
> + /* Attempt to correct the framebuffer settings */
> + if (fbdev_set_screen_info(fd, screen_info) < 0) {
> + weston_log("Failed to set mode settings. "
> + "Attempting to open output anyway.\n");
> + }
> +
> +
> return fd;
> }
>
Hi,
I think the existing code is a trap. fbdev_query_screen_info() asks the
fbdev what format it has, and then computes a Pixman format code from
it, which the renderer will then use. But, fbdev_set_screen_info() has
a hardcoded pixel format it tries to set.
If the original format on the fbdev is not the hardcoded format in
fbdev_set_screen_info(), and fbdev_set_screen_info() actually succeeds,
then the rendered format is wrong.
I believe that all DRM drivers providing fbdev via the shared fbdev
emulation always use the one format that matches the hardcoded one in
fbdev_set_screen_info(), and we get lucky. If someone tried this on a
"normal" fb driver, I think there is a chance to go wrong.
Do we care? I don't. Therefore:
Reviewed-by: Pekka Paalanen <pekka.paala...@collabora.co.uk>
Thanks,
pq
pgpD4cXjViA2t.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
