[PATCH] Add m1bpp (monochrome, 1 bit/pixel) pixel format

[Pekka Paalanen]

On Fri, 15 Sep 2017 08:43:18 -0400
Drew DeVault <sir at cmpwn.com> wrote:

> On 2017-09-15  1:41 PM, Emil Velikov wrote:
> > Can you add some commit message where this format is doing to be used, how?
> > I'm not sure what Wayland devs' stance is on s-o-b line is, but I'd
> > imagine they won't object to it.  
> 
> Sure! I'm doing some hacking on the ZeroPhone[1], which has a 128x64
> 1bpp monochrome display that I want to drive with a Wayland compositor.
> I'll add this detail to the patch in a few days, to leave some time
> for further discussion before shooting out a new patch.
> 
> [1] https://github.com/ZeroPhone/

Hi,

I'm sure you knew this, but you don't need this protocol addition just
for driving the display. I guess you want this protocol addition so
that you can write clients that draw directly in the 1-bit format so
they don't waste 8x the memory (there are already 8-bit formats). The
latter would be nice to mention in the commit message as it answers the
"why".

> +      <entry name="m1bpp" value="2" summary="1-bit monochrome format, 8 pixels per octet, ordered most to least significant bit" />

If I understand right, the definition means that to read pixel x on a
row, one computes:

((*((uint8_t *)row_begin + x / 8)) >> (7 - x % 8)) & 1

Is that correct, regardless of machine endianess?

I ask about endianess, because Pixman has some fun pixel formats where
endianess is defined to affect also the order of bits, not just bytes.

All in all, the patch is perfectly logical. It adds a new format with a
new name that I believe does not clash with drm_fourcc.h formats in
either name nor numerical code. There is no need to bump the interface
versions, because adding a new enum value in this case cannot provoke
any unexpected conditions: a server advertises a set of formats to
clients; if a client does not understand a format it just ignores it;
if a server does not understand a format client used, the client gets
disconnected anyway since the server did not advertise it.

Curious, given that drm_fourcc.h does not have any 1-bit formats
defined, what kernel ABI does that display use?

Indeed, 2 and 4 bit formats are also missing, but 8 and 16 bit ones are
already defined unless you meant some new variation.

I am cautiously positive about this patch. Cautious, because it adds
one more format that does not follow drm_fourcc. I think it's fine
though.


Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20170915/d1977b29/attachment.sig>