[MPlayer-dev-eng] [PATCH] Color Support for Blinkenlights Output Module

[Reimar Döffinger]

On Sun, Dec 29, 2013 at 08:29:44PM +0100, Stefan Schuermans wrote:
> @@ -306,7 +310,8 @@
>  
>  static int query_format(uint32_t format) {
>  	if (format == bl->img_format)
> -		return VFCAP_CSP_SUPPORTED|VFCAP_CSP_SUPPORTED_BY_HW;
> +		return VFCAP_CSP_SUPPORTED | VFCAP_CSP_SUPPORTED_BY_HW |
> +		       VFCAP_ACCEPT_STRIDE;
>  	return 0;


This seems kind of unrelated?

> @@ -330,12 +335,12 @@
>  static int draw_slice(uint8_t *srcimg[], int stride[],
>  		int w, int h, int x, int y) {
>  	int i;
> -	uint8_t *dst = image + y * bl->width + x;
> +	uint8_t *dst = image + (y * bl->width + x) * bl->channels;
>  	uint8_t *src=srcimg[0];
> -	// copy Y:
> +	// copy Y or RGB data
>  	for (i = 0; i < h; i++) {
> -		fast_memcpy(dst,src,w);
> -		dst+=bl->width;
> +		fast_memcpy(dst,src,w*bl->channels);
> +		dst+=bl->width*bl->channels;
>  		src+=stride[0];
>  
>  	}


Hm, I was assuming that draw_slice wouldn't normally be used for RGB.
(slightly unrelated): Strangely, it seems that many allocations use a multiplication by a
constant "3" which seems a bit strange.
E.g. what is the point of this:
>                bl_size = 12 + bl->width*bl->height*bl->channels;
>                bl_packet = malloc(12 + bl->width*bl->height*3); /* space for header and image data */

Same applies to some memset/memcpys. Completely unrelated, I wonder why flip_page introduces a full 1 frame delay,
and even uses a full memcpy to do so (which is silly either way, double-buffering would make a lot more sense,
if I could see any sense in the delay in the first place).
I suspect that a bit of code cleanup wouldn't hurt, even though that probably isn't as much fun as
watching colourful LEDs ;-)