[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] Modifying xenfb colour depth from Android domU
I'm facing some problems getting xenfb to work with an Android domU, on ARM. The issue is that the framebuffer is created with a depth of 32bpp, while the Android guest is rendering RGB565. I tried to fix this by using the fbdev API to request a change of pixel format, during the Android startup: int set_fb_pixel_format() { int fd = open("/dev/graphics/fb0", O_RDWR, 0); struct fb_var_screeninfo info; if (ioctl(fd, FBIOGET_VSCREENINFO, &info) == -1) { return -errno; } info.red.offset = 11; info.red.length = 5; info.green.offset = 5; info.green.length = 6; info.blue.offset = 0; info.blue.length = 5; info.transp.offset = 0; info.transp.length = 0; info.bits_per_pixel = 16; info.activate = FB_ACTIVATE_NOW; if (ioctl(fd, FBIOPUT_VSCREENINFO, &info) == -1) { ALOGE("Selecting RGB565 failed"); return -errno; } ... } This however fails in the xen-fbfront driver, due to bits_per_pixel not matching the current framebuffer depth (which comes from #define XENFB_DEPTH 32): static int xenfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info) { ... if (var->bits_per_pixel == xenfb_info->page->depth && var->xres <= info->fix.line_length / (XENFB_DEPTH / 8) && required_mem_len <= info->fix.smem_len) { var->xres_virtual = var->xres; var->yres_virtual = var->yres; return 0; } return -EINVAL; } I found that I can fix this in one of two ways: 1. Change the initial depth to 16. This of course means that guest rendering in other depths is incorrectly displayed. diff --git a/include/xen/interface/io/fbif.h b/include/xen/interface/io/fbif.h index 974a51e..42b1258 100644 --- a/include/xen/interface/io/fbif.h +++ b/include/xen/interface/io/fbif.h @@ -137,7 +137,7 @@ struct xenfb_page { #ifdef __KERNEL__ #define XENFB_WIDTH 800 #define XENFB_HEIGHT 600 -#define XENFB_DEPTH 32 +#define XENFB_DEPTH 16 #endif 2. Allow the guest to modify the framebuffer depth. diff --git a/drivers/video/xen-fbfront.c b/drivers/video/xen-fbfront.c index 02e1c01..b65a485 100644 --- a/drivers/video/xen-fbfront.c +++ b/drivers/video/xen-fbfront.c @@ -295,12 +295,11 @@ xenfb_check_var(struct fb_var_screeninfo *var, struct fb_info *info) if (var->xres > video[KPARAM_WIDTH] || var->yres > video[KPARAM_HEIGHT]) return -EINVAL; - required_mem_len = var->xres * var->yres * xenfb_info->page->depth / 8; - if (var->bits_per_pixel == xenfb_info->page->depth && - var->xres <= info->fix.line_length / (XENFB_DEPTH / 8) && - required_mem_len <= info->fix.smem_len) { + required_mem_len = var->xres * var->yres * var->bits_per_pixel / 8; + if (required_mem_len <= info->fix.smem_len) { var->xres_virtual = var->xres; var->yres_virtual = var->yres; + info->fix.line_length = var->xres * var->bits_per_pixel / 8; return 0; } return -EINVAL; This works for my case, but involves modifying the fb_info.fix.line_length value - is this allowed? Code being used: linux: refs/tags/v3.10.16, plus "b1a3b1c xen/fb: allow xenfb initialization for hvm guests" qemu: refs/tags/v2.1.0-rc3 xen: refs/tags/RELEASE-4.4.0 Note that xenfb_check_var is unchanged in linux master. Gareth -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |