[fbdev_backend]: support of DIRECTCOLOR Frame buffer

Pekka Paalanen ppaalanen at gmail.com
Tue Jun 11 06:59:17 PDT 2013


On Tue, 11 Jun 2013 15:15:29 +0200
Marc Chalain <marc.chalain at gmail.com> wrote:

> Hello,
> OK this patch now checks FB_VISUAL_DIRECTCOLOR twice but set the cmap
> inside the fbdev_query_screen_info function.
> I use "malloc" instead "table" declaration because it takes less memory and
> it's used only once, it's useless to be faster.
> 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.

What I meant is, if rcols = 32 and gcols = 64, you allocate a 64-long
array, and fill it with 64 step values. Does that not mean, that the
maximum red color will be only 50% intensity, because it goes only up to
32 steps, and the remaining 32 steps will never be used?

Or am I misunderstanding how fbdev colormap works?

> 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;

IOW, should this divisor not be per channel, instead of using the same
for all channels?

In fact, you are using rcols in the divisor here, so if cols > rcols...
no wait...

> +
> +    cmap.start = 0;
> +    cmap.len = cols;

Here you use cols, but the loop uses rcols. How does this make sense?

> +    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;

The last two hunks look good now.


Thanks,
pq


More information about the wayland-devel mailing list