<div dir="ltr"><div><div><div><div>Hello, </div>OK this patch now checks FB_VISUAL_DIRECTCOLOR twice but set the cmap inside the fbdev_query_screen_info function. </div>I use "malloc" instead "table" declaration because it takes less memory and it's used only once, it's useless to be faster. </div>After I set the same values for each colors, because it's a default map. To set more finely we have to know the screen and it's capabilities. </div>I don't set the alpha when it's required (no alpha => no alpha map) [PATCH] [compositor-fbdev]: DirectColor support The backend accepts to use TRUECOLOR and DIRECTCOLOR which are similares. DIRECTCOLOR has better results if the application applies a Colors map before to use it. The colors map is just a list of gradients for each colors and alpha. --- src/compositor-fbdev.c | 43 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 42 insertions(+), 1 deletion(-) diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c index 9c3d17e..c966d5a 100644 --- a/src/compositor-fbdev.c +++ b/src/compositor-fbdev.c @@ -203,6 +203,43 @@ finish_frame_handler(void *data) return 1; } +static int +set_cmap(int fd, struct fb_var_screeninfo *vinfo) +{ + struct fb_cmap cmap; + uint16_t *colors; + int i; + int rcols = 1 << vinfo->red.length; + int gcols = 1 << vinfo->green.length; + int bcols = 1 << vinfo->blue.length; + + memset(&cmap, 0, sizeof(cmap)); + + /* Make our palette the length of the deepest color */ + int cols = (rcols > gcols ? rcols : gcols); + cols = (cols > bcols ? cols : bcols); + + colors = malloc(sizeof(uint16_t) * cols); + if (!colors) return -1; + + for (i = 0; i < rcols; i++) + colors[i] = (UINT16_MAX / (rcols - 1)) * i; + + cmap.start = 0; + cmap.len = cols; + cmap.red = colors; + cmap.blue = colors; + cmap.green = colors; + if (vinfo->transp.length) + cmap.transp = colors; + else + cmap.transp = NULL; + ioctl(fd, FBIOPUTCMAP, &cmap); + + free(colors); + return 0; +} + static pixman_format_code_t calculate_pixman_format(struct fb_var_screeninfo *vinfo, struct fb_fix_screeninfo *finfo) @@ -242,7 +279,8 @@ calculate_pixman_format(struct fb_var_screeninfo *vinfo, return 0; /* We only handle true-colour frame buffers at the moment. */ - if (finfo->visual != FB_VISUAL_TRUECOLOR || vinfo->grayscale != 0) + if (!(finfo->visual == FB_VISUAL_TRUECOLOR || finfo->visual == FB_VISUAL_DIRECTCOLOR) + || vinfo->grayscale != 0) return 0; /* We only support formats with MSBs on the left. */ @@ -325,6 +363,9 @@ fbdev_query_screen_info(struct fbdev_output *output, int fd, info->pixel_format = calculate_pixman_format(&varinfo, &fixinfo); info->refresh_rate = calculate_refresh_rate(&varinfo); + if (fixinfo.visual == FB_VISUAL_DIRECTCOLOR) + set_cmap(fd, &varinfo); + if (info->pixel_format == 0) { weston_log("Frame buffer uses an unsupported format.\n"); return -1; -- 1.7.9.5 </div><div class="gmail_extra"> <div class="gmail_quote">2013/6/10 Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Fri, 7 Jun 2013 17:13:59 +0200 Marc Chalain <<a href="mailto:marc.chalain@gmail.com">marc.chalain@gmail.com</a>> wrote: > From e30486e0288e7be526fc358a5318b344522e407b Mon Sep 17 00:00:00 2001 > From: mchalain <<a href="mailto:marc.chalain@gmail.com">marc.chalain@gmail.com</a>> > Date: Fri, 7 Jun 2013 17:12:31 +0200 > Subject: [PATCH] [fbdev_backend]: support of DIRECTCOLOR Frame buffer > </div>A properly formatted title: compositor-fbdev: add direct color support Commit message is missing. <div><div class="h5"> > --- > src/compositor-fbdev.c | 49 > +++++++++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 46 insertions(+), 3 deletions(-) > > diff --git a/src/compositor-fbdev.c b/src/compositor-fbdev.c > index 9c3d17e..d6d911a 100644 > --- a/src/compositor-fbdev.c > +++ b/src/compositor-fbdev.c > @@ -203,9 +203,42 @@ finish_frame_handler(void *data) > return 1; > } > > +static int > +build_cmap(struct fb_var_screeninfo *vinfo, > + struct fb_cmap *cmap) > +{ > + uint16_t *colors; > + int i; > + int rcols = 1 << vinfo->red.length; > + int gcols = 1 << vinfo->green.length; > + int bcols = 1 << vinfo->blue.length; > + > + /* Make our palette the length of the deepest color */ > + int cols = (rcols > gcols ? rcols : gcols); > + cols = (cols > bcols ? cols : bcols); > + > + colors = malloc(sizeof(uint16_t) * cols); > + if (!colors) return -1; > + > + for (i = 0; i < rcols; i++) > + colors[i] = (UINT16_MAX / (rcols - 1)) * i; > + > + cmap->start = 0; > + cmap->len = cols; > + cmap->red = colors; > + cmap->blue = colors; > + cmap->green = colors; </div></div>If there actually is a difference between rcols, gcols, and bcols, should you not compute a different a 'colors' array for each different _cols? <div class="im"> > + if (vinfo->transp.length) > + cmap->transp = colors; > + else > + cmap->transp = NULL; </div>Now, 'colors' is malloc'd here. How does the caller of this function know what to free? Freeing each of cmap->{red,blue,green,transp} would lead to double-free errors. Right, you free only 'red'. But that's rather surprising. <div class="im"> > + return 0; > +} > + > static pixman_format_code_t > calculate_pixman_format(struct fb_var_screeninfo *vinfo, > - struct fb_fix_screeninfo *finfo) > + struct fb_fix_screeninfo *finfo, > + struct fb_cmap *cmap) > { > /* Calculate the pixman format supported by the frame buffer from the > * buffer's metadata. Return 0 if no known pixman format is supported > @@ -241,7 +274,10 @@ calculate_pixman_format(struct fb_var_screeninfo > *vinfo, > if (finfo->type != FB_TYPE_PACKED_PIXELS) > return 0; > > - /* We only handle true-colour frame buffers at the moment. */ > + if (finfo->visual == FB_VISUAL_DIRECTCOLOR) > + build_cmap(vinfo, cmap); </div>This is a strange place to call build_cmap(). The purpose of this function is to return a pixman format or an error, not to fill a fb_cmap struct. Yes, you probably need to test for FB_VISUAL_DIRECTCOLOR in two places. <div><div class="h5"> > + else > + /* We only handle true-colour frame buffers at the moment. */ > if (finfo->visual != FB_VISUAL_TRUECOLOR || vinfo->grayscale != 0) > return 0; > > @@ -304,6 +340,9 @@ fbdev_query_screen_info(struct fbdev_output *output, > int fd, > { > struct fb_var_screeninfo varinfo; > struct fb_fix_screeninfo fixinfo; > + struct fb_cmap cmap; > + > + memset(&cmap, 0, sizeof(cmap)); > > /* Probe the device for screen information. */ > if (ioctl(fd, FBIOGET_FSCREENINFO, &fixinfo) < 0 || > @@ -322,9 +361,13 @@ fbdev_query_screen_info(struct fbdev_output *output, > int fd, > info->line_length = fixinfo.line_length; > strncpy(info->id, <a href="http://fixinfo.id" target="_blank">fixinfo.id</a>, sizeof(info->id) / sizeof(*info->id)); > > - info->pixel_format = calculate_pixman_format(&varinfo, &fixinfo); > + info->pixel_format = calculate_pixman_format(&varinfo, &fixinfo, > &cmap); > info->refresh_rate = calculate_refresh_rate(&varinfo); > > + if (cmap.red != NULL) { > + ioctl(fd, FBIOPUTCMAP, &cmap); > + free(cmap.red); > + } > if (info->pixel_format == 0) { > weston_log("Frame buffer uses an unsupported format.\n"); > return -1; </div></div>This patch is indented with 4 spaces, while weston codebase uses hard tabs of width 8. Maybe your email client messed up the whitespace? I also see a few lines cut unintendedly. Thanks pq </blockquote></div> </div>