On Wed, Sep 05, 2018 at 04:37:26PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 05, 2018 at 03:19:03PM +0200, Maxime Ripard wrote:
> > On Wed, Sep 05, 2018 at 01:14:34PM +0300, Ville Syrjälä wrote:
> > > > In the same format list:
> > > >   - RGB565 has a depth of 16
> > > >   - XRGB8888 has a depth of 24
> > > >   - XRGB2101010 has a depth of 30
> > > >   - ARGB8888 has a depth of 32
> > > > 
> > > > Which seems to indicate that the list indeed meant that the color
> > > > depth is about the color, and that ARGB8888 is wrong.
> > > 
> > > None of those other things have alpha, so they are still
> > > consistent with the depth==32 definition for ARGB888.
> > 
> > "24 bits almost always uses 8 bits of each of R, G, B. As of 2018
> > 24-bit color depth is used by virtually every computer and phone
> > display and the vast majority of image storage formats. Almost all
> > cases where there are 32 bits per pixel mean that 24 are used for the
> > color, and the remaining 8 are the alpha channel or unused."
> > 
> > There's 32bpp, but the depth is 24 bits.
> > 
> > But maybe the X11 legacy says otherwise, I don't know. What's your
> > suggestion then? adding yet another field?
> 
> Just leave it as is?

I need the actual color depth in order to check whether the conversion
from one format to another would lead to a lesser number of bits per
color, and as such should fall back to a more conservative
pattern. See the later patches in this series.

Maxime

-- 
Maxime Ripard, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com