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

[Pekka Paalanen]

On Thu, 21 Sep 2017 10:08:06 -0400
Drew DeVault <sir at cmpwn.com> wrote:

> This is useful for Wayland compositors on low-end displays - in
> my use case, this is the Heltec 1.3" SPI OLED display. It permits
> compatible Wayland clients to utilize a more suitable pixel format for
> writing to the display for greater fidelity and performance.
> ---
> The only changes from the previous patch is an improved commit message.
> 
>  protocol/wayland.xml | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> index 29b63be..2f72939 100644
> --- a/protocol/wayland.xml
> +++ b/protocol/wayland.xml
> @@ -291,6 +291,7 @@
>        </description>
>        <entry name="argb8888" value="0" summary="32-bit ARGB format, [31:0] A:R:G:B 8:8:8:8 little endian"/>
>        <entry name="xrgb8888" value="1" summary="32-bit RGB format, [31:0] x:R:G:B 8:8:8:8 little endian"/>
> +      <entry name="m1bpp" value="2" summary="1-bit monochrome format, 8 pixels per octet, ordered most to least significant bit" />
>        <entry name="c8" value="0x20203843" summary="8-bit color index format, [7:0] C"/>
>        <entry name="rgb332" value="0x38424752" summary="8-bit RGB format, [7:0] R:G:B 3:3:2"/>
>        <entry name="bgr233" value="0x38524742" summary="8-bit BGR format, [7:0] B:G:R 2:3:3"/>

Hi Drew,

I'm hesitant to add "invented" pixel format codes here, referring to
the value 2. But I suppose drm_fourcc.h does not define anything 1-bit.
If it seems unlikely for drm_fourcc.h to accept a 1-bit format, then
ok. But if it could be useful with a GPU or a display chip, then I'd
recommend trying to get it into DRM first.

Actually,

<+ajax> i'm reasonably sure there does exist hardware with at least some "R1" support
<+ajax> hm. DXGI_FORMAT_R1_UNORM exists, though it's super limited.
<+ajax> yes i meant gpu. but i think we're still going to see monochrome display controllers forever.
<+ajax> e-paper exists, after all
<+ajax> and i guess it doesn't really matter much whether you call that one channel L or R or A
<+ajax> so yeah, i'd take a 1bpp format i think

So getting it into DRM sounds plausible. Then we can just copy the
definition into Wayland with the confidence that the format value
cannot conflict with anything else we might get.


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/20200130/df0d06be/attachment.sig>