search for: sdvga

...f > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code appears to interpret them as native endian though. Lets take a simple example, the bochs driver (qemu sdvga). It supports 32 bpp with depth 24 (DRM_FORMAT_XRGB8888) as the one and only framebuffer format (see bochs_user_framebuffer_create). We still had to add a special register to the virtual hardware so the guest can signal to the host whenever the framebuffer is big endian or little endian (see boch...

...f > > DRM formats are supposed to be little endian, so this isn't really > correct. Well, maybe they where *intended* to be little endian at some point in the past. The actual code appears to interpret them as native endian though. Lets take a simple example, the bochs driver (qemu sdvga). It supports 32 bpp with depth 24 (DRM_FORMAT_XRGB8888) as the one and only framebuffer format (see bochs_user_framebuffer_create). We still had to add a special register to the virtual hardware so the guest can signal to the host whenever the framebuffer is big endian or little endian (see boch...

...ed to be little endian, so this isn't really > > correct. > > Well, maybe they where *intended* to be little endian at some point in > the past. The actual code appears to interpret them as native endian > though. > > Lets take a simple example, the bochs driver (qemu sdvga). It supports > 32 bpp with depth 24 (DRM_FORMAT_XRGB8888) as the one and only > framebuffer format (see bochs_user_framebuffer_create). We still had to > add a special register to the virtual hardware so the guest can signal > to the host whenever the framebuffer is big endian or lit...

...'t really > > > correct. > > > > Well, maybe they where *intended* to be little endian at some point in > > the past. The actual code appears to interpret them as native endian > > though. > > > > Lets take a simple example, the bochs driver (qemu sdvga). It supports > > 32 bpp with depth 24 (DRM_FORMAT_XRGB8888) as the one and only > > framebuffer format (see bochs_user_framebuffer_create). We still had to > > add a special register to the virtual hardware so the guest can signal > > to the host whenever the framebuffer...

...'t really > > > correct. > > > > Well, maybe they where *intended* to be little endian at some point in > > the past. The actual code appears to interpret them as native endian > > though. > > > > Lets take a simple example, the bochs driver (qemu sdvga). It supports > > 32 bpp with depth 24 (DRM_FORMAT_XRGB8888) as the one and only > > framebuffer format (see bochs_user_framebuffer_create). We still had to > > add a special register to the virtual hardware so the guest can signal > > to the host whenever the framebuffer...

When we use virtio-vga with a big-endian guest, the mouse pointer disappears. To fix that, on big-endian use DRM_FORMAT_BGRA8888 instead of DRM_FORMAT_ARGB8888. Signed-off-by: Laurent Vivier <lvivier at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c

When we use virtio-vga with a big-endian guest, the mouse pointer disappears. To fix that, on big-endian use DRM_FORMAT_BGRA8888 instead of DRM_FORMAT_ARGB8888. Signed-off-by: Laurent Vivier <lvivier at redhat.com> --- drivers/gpu/drm/virtio/virtgpu_plane.c | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c