linux-kernel - Re: [PATCH] fbdev: fix color component field length documentation

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <10f740e80903310018v7e12de88m696f07e40dc617e3@mail.gmail.com>
Date:	Tue, 31 Mar 2009 09:18:09 +0200
From:	Geert Uytterhoeven <geert@...ux-m68k.org>
To:	spock@...too.org
Cc:	linux-kernel@...r.kernel.org,
	Krzysztof Helt <krzysztof.h1@...zta.fm>,
	Ville Syrjälä <syrjala@....fi>,
	linux-fbdev-devel@...ts.sourceforge.net
Subject: Re: [PATCH] fbdev: fix color component field length documentation

On Tue, Mar 31, 2009 at 00:00, Michal Januszewski <spock@...too.org> wrote:
> The documentation about the meaning of the color component bitfield lengths
> in pseudocolor modes is inconsistent.  Fix it, so that it indicates the
> correct interpretation everywhere, i.e. that the 1 << length is the number
> of palette entries.
>
> Signed-off-by: Michal Januszewski <spock@...too.org>
> Cc: Krzysztof Helt <krzysztof.h1@...zta.fm>
> Cc: Ville Syrjälä <syrjala@....fi>
> Cc: Geert Uytterhoeven <geert.uytterhoeven@...il.com>

Acked-by: Geert Uytterhoeven <geert@...ux-m68k.org>

Except for this:

> --- a/include/linux/fb.h
> +++ b/include/linux/fb.h
> @@ -172,8 +172,11 @@ struct fb_fix_screeninfo {
>  /* Interpretation of offset for color fields: All offsets are from the right,
>  * inside a "pixel" value, which is exactly 'bits_per_pixel' wide (means: you
>  * can use the offset as right argument to <<). A pixel afterwards is a bit
> - * stream and is written to video memory as that unmodified. This implies
> - * big-endian byte order if bits_per_pixel is greater than 8.
> + * stream and is written to video memory as that unmodified.
> + *
> + * For pseudocolor, offset is always 0 and length, which should be the same
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is not correct. Offset can be non-zero, e.g. for a 8 bpp frame buffer with
64 palette entries, where the palette index is stored in the upper 6 bits of the
8-bit pixel value, offset would be 2, and length would be 6.
Not that I've seen that (so far)...

> + * for all color components, indicates the number of available palette entries
> + * (i.e. # of entries = 1 << length).
>  */
>  struct fb_bitfield {
>        __u32 offset;                   /* beginning of bitfield        */
>

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/