Add m1bpp (monochrome, 1 bit/pixel) pixel format

Submitted by Drew DeVault on Sept. 14, 2017, 8:08 p.m.

Details

Message ID 20170914200843.GA17821@miku
State Superseded
Headers show
Series "Add m1bpp (monochrome, 1 bit/pixel) pixel format" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Drew DeVault Sept. 14, 2017, 8:08 p.m.
---
This patch is pretty straightforward, it does what it says on the tin.
I'm interested in developing wayland compositors for monochrome
displays.

It may also make sense to add other pixel formats, like 2bpp/4bpp
(grayscale), or 8-bit/16-bit color.

 protocol/wayland.xml | 1 +
 1 file changed, 1 insertion(+)

Patch hide | download patch | download mbox

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"/>

Comments

Hi Drew,

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.

On 14 September 2017 at 21:08, Drew DeVault <sir@cmpwn.com> wrote:
> ---
> This patch is pretty straightforward, it does what it says on the tin.
> I'm interested in developing wayland compositors for monochrome
> displays.
>
> It may also make sense to add other pixel formats, like 2bpp/4bpp
> (grayscale), or 8-bit/16-bit color.
>
>  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" />

I believe that all the formats* are analogous to the ones used in the
kernel, as defined in drm_fourcc.h.
Is there such an equivalent, if not should one consider adding one first?

HTH
Emil
*  Barring wl_shm's 0 and 1, because hysterical raisins
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/

--
Drew DeVault
I missed this from your earlier email:

>I believe that all the formats* are analogous to the ones used in the
>kernel, as defined in drm_fourcc.h.
>Is there such an equivalent, if not should one consider adding one first?

Adding support for this screen in Linux is an interesting idea... but
perhaps too much work for too little gain. It can't be GPU accellerated
so DRM doesn't give much value-add here.

Some formats here, namely argb8888 and xrgb8888, have values that are
not derived from DRM, which is why I grouped m1bpp alongside them rather
than at the end of the list. This patch doesn't set a new precedent in
that regard.

--
Drew DeVault
On Fri, 15 Sep 2017 08:43:18 -0400
Drew DeVault <sir@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
On Fri, 15 Sep 2017 10:59:56 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> I missed this from your earlier email:
> 
> >I believe that all the formats* are analogous to the ones used in the
> >kernel, as defined in drm_fourcc.h.
> >Is there such an equivalent, if not should one consider adding one first?  
> 
> Adding support for this screen in Linux is an interesting idea... but
> perhaps too much work for too little gain. It can't be GPU accellerated
> so DRM doesn't give much value-add here.

DRM is for driving any kind of display, GPU or not, acceleratable or
not. What it gives us is a standard userspace ABI to poke all display
devices with.

There could be other reasons to not write a DRM driver, but "only for
GPU stuff" is not one.


Thanks,
pq
On 2017-09-15  6:06 PM, Pekka Paalanen wrote:
> 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".

Yes, your surmising is correct. I'll add it to the commit message.

> ((*((uint8_t *)row_begin + x / 8)) >> (7 - x % 8)) & 1
> 
> Is that correct, regardless of machine endianess?

Yes.

> 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.

This is such a format, and in theory the opposite endianness could
exist, though I've never observed it in practice. The language in the
description is sufficient to understand how to use this pixel format on
any particular architecture.

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

This display doesn't have a kernel driver that I'm aware of. Most
applications drive it with GPIO.

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

The 8 and 16 bit ones, so far as I can tell, are 8/16 bits per component
of an RGB(A) triple (quadruple), rather than 8/16 bits per pixel.
On 2017-09-15  6:17 PM, Pekka Paalanen wrote:
> DRM is for driving any kind of display, GPU or not, acceleratable or
> not. What it gives us is a standard userspace ABI to poke all display
> devices with.
> 
> There could be other reasons to not write a DRM driver, but "only for
> GPU stuff" is not one.

Good to know, thanks for clarifying. I hadn't dug that deeply into it.
You're correct, though, that there are other reasons not to add it to
DRM. There's no standard way of connecting this display to your
computer, and there would be cause for users to want to do it
differently if an attempt at standardization was made. That's probably a
solvable problem, but would require extending DRM in ways that aren't
really worth the trouble imo. It'd be cool, though.

--
Drew DeVault
Hi Drew,

On 15 September 2017 at 16:21, Drew DeVault <sir@cmpwn.com> wrote:
> On 2017-09-15  6:17 PM, Pekka Paalanen wrote:
>> DRM is for driving any kind of display, GPU or not, acceleratable or
>> not. What it gives us is a standard userspace ABI to poke all display
>> devices with.
>>
>> There could be other reasons to not write a DRM driver, but "only for
>> GPU stuff" is not one.
>
> Good to know, thanks for clarifying. I hadn't dug that deeply into it.
> You're correct, though, that there are other reasons not to add it to
> DRM. There's no standard way of connecting this display to your
> computer, and there would be cause for users to want to do it
> differently if an attempt at standardization was made. That's probably a
> solvable problem, but would require extending DRM in ways that aren't
> really worth the trouble imo. It'd be cool, though.

I don't think it would involve extending DRM at all. DRM already
handles all kinds of weird panels, connected through SPI, bit-banged
I2C, DSI, and any number of transports. A lot of these require
per-platform definitions of how the panel is connected, which is done
via DeviceTree. You can look at almost any driver to see how this is
done.

Cheers,
Daniel
On Fri, 15 Sep 2017 11:17:29 -0400
Drew DeVault <sir@cmpwn.com> wrote:

> On 2017-09-15  6:06 PM, Pekka Paalanen wrote:
> > 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.  
> 
> This is such a format, and in theory the opposite endianness could
> exist, though I've never observed it in practice. The language in the
> description is sufficient to understand how to use this pixel format on
> any particular architecture.

To be exact, I was referring to this bit of code:

https://cgit.freedesktop.org/pixman/tree/pixman/pixman-access.c?h=0.34&id=pixman-0.34.0#n51

Depending on endianess, it starts counting from either MSB or LSB.

If we can be sure we never want to start counting from LSB, we're good.
Or just add another format.

> > Indeed, 2 and 4 bit formats are also missing, but 8 and 16 bit ones are
> > already defined unless you meant some new variation.  
> 
> The 8 and 16 bit ones, so far as I can tell, are 8/16 bits per component
> of an RGB(A) triple (quadruple), rather than 8/16 bits per pixel.

There are 8 and 16 bits per pixel: c8, rgb332, rgb565, argb4444,
argb1555, etc.


Thaks,
pq
On Friday, 2017-09-15 11:17:29 -0400, Drew DeVault wrote:
> On 2017-09-15  6:06 PM, Pekka Paalanen wrote:
> > Indeed, 2 and 4 bit formats are also missing, but 8 and 16 bit ones are
> > already defined unless you meant some new variation.
> 
> The 8 and 16 bit ones, so far as I can tell, are 8/16 bits per component
> of an RGB(A) triple (quadruple), rather than 8/16 bits per pixel.

You're thinking about 24/32 bpp formats there, such as DRM_FORMAT_RGB888
or DRM_FORMAT_ARGB8888, but there are smaller ones. Since you only care
about one component, you could also use DRM_FORMAT_R8 [1] or
DRM_FORMAT_R16, which are 8 and 16 bits per pixel.

[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/drm/drm_fourcc.h#n41