[ANNOUNCE] pixfmtdb

[Simon Ser]

Hi all,

In the last few days I've been working on a small new project, pixfmtdb [1].
It's a Web database of pixel format guides, it can be useful to understand
how pixels are laid out in memory for a given format and which formats from
various APIs are compatible with each other.

pixfmtdb relies on the Khronos Data Format Specification [2] to describe
each format. This means that each format is described with a standardized
data blob, which can be re-used with other tools for other purposes.

My future plans include adding more formats and format families to pixfmtdb,
and make it easy to use the data for code generation, in particular for
automatically generating tables containing metadata about formats, as used
in Wayland compositors and other projects.

I hope some of you can find this work useful,

Simon

[1]: https://pixfmtdb.emersion.fr
[2]: https://www.khronos.org/dataformat

Re: [ANNOUNCE] pixfmtdb

[Laurent Pinchart]

CC'ing the linux-media mailing list.

On Mon, Jan 23, 2023 at 02:10:58PM +, Simon Ser wrote:
> Hi all,
> 
> In the last few days I've been working on a small new project, pixfmtdb [1].
> It's a Web database of pixel format guides, it can be useful to understand
> how pixels are laid out in memory for a given format and which formats from
> various APIs are compatible with each other.
> 
> pixfmtdb relies on the Khronos Data Format Specification [2] to describe
> each format. This means that each format is described with a standardized
> data blob, which can be re-used with other tools for other purposes.
> 
> My future plans include adding more formats and format families to pixfmtdb,
> and make it easy to use the data for code generation, in particular for
> automatically generating tables containing metadata about formats, as used
> in Wayland compositors and other projects.
> 
> I hope some of you can find this work useful,
> 
> Simon
> 
> [1]: https://pixfmtdb.emersion.fr
> [2]: https://www.khronos.org/dataformat

-- 
Regards,

Laurent Pinchart

Re: Retiring the GitHub mirrors

[Alyssa Rosenzweig]

> Among the people present in this discussion, the consensus was that we
> should delete them.

I wasn't present but +1 from me.

Debugging weston-launch

[Edgar Mobile]

I have to debug an Aarch64 based Linux system where weston-launch gets stuck in 
the main loop poll:

https://gitlab.freedesktop.org/wayland/weston/-/blob/master/libweston/weston-launch.c#L905
[https://gitlab.freedesktop.org/assets/twitter_card-570ddb06edf56a2312253c5872489847a0f385112ddbcd71ccfa1570febab5d2.jpg]
libweston/weston-launch.c · master · wayland / weston · 
GitLab
A lightweight and functional Wayland compositor. Switch branch/tag. weston 
libweston; weston-launch.c
gitlab.freedesktop.org
Can someone tell me how to start debugging this?

Regards.

Re: [ANNOUNCE] pixfmtdb

[Sebastian Wick]

Why is the TF defined for GL formats and both the primaries and TF for
Vulkan formats? The only exception here should be sRGB formats. Where
did you get the information from?

On Mon, Jan 23, 2023 at 4:51 PM Laurent Pinchart
 wrote:
>
> CC'ing the linux-media mailing list.
>
> On Mon, Jan 23, 2023 at 02:10:58PM +, Simon Ser wrote:
> > Hi all,
> >
> > In the last few days I've been working on a small new project, pixfmtdb [1].
> > It's a Web database of pixel format guides, it can be useful to understand
> > how pixels are laid out in memory for a given format and which formats from
> > various APIs are compatible with each other.
> >
> > pixfmtdb relies on the Khronos Data Format Specification [2] to describe
> > each format. This means that each format is described with a standardized
> > data blob, which can be re-used with other tools for other purposes.
> >
> > My future plans include adding more formats and format families to pixfmtdb,
> > and make it easy to use the data for code generation, in particular for
> > automatically generating tables containing metadata about formats, as used
> > in Wayland compositors and other projects.
> >
> > I hope some of you can find this work useful,
> >
> > Simon
> >
> > [1]: https://pixfmtdb.emersion.fr
> > [2]: https://www.khronos.org/dataformat
>
> --
> Regards,
>
> Laurent Pinchart
>

Re: [ANNOUNCE] pixfmtdb

[Simon Ser]

On Monday, January 23rd, 2023 at 21:25, Sebastian Wick 
 wrote:

> Why is the TF defined for GL formats and both the primaries and TF for
> Vulkan formats? The only exception here should be sRGB formats. Where
> did you get the information from?

This is what upstream dfdutils does [1]. Can you explain why you think
it should be undefined instead of linear?

I was wondering what to do for DRM formats regarding these. I think it
would be worthwhile to do like Vulkan: set TF = linear, primaries =
BT.709, pre-multiplied alpha = yes. These are the things KMS assume
when there is no override (ie, when there is no KMS property saying
otherwise).

[1]: 
https://github.com/KhronosGroup/dfdutils/blob/5cd41cbdf63e80b00c085c6906a1152709e4c0f2/createdfd.c#L47

Re: [ANNOUNCE] pixfmtdb

[Sebastian Wick]

On Mon, Jan 23, 2023 at 11:43 PM Simon Ser  wrote:
>
> On Monday, January 23rd, 2023 at 21:25, Sebastian Wick 
>  wrote:
>
> > Why is the TF defined for GL formats and both the primaries and TF for
> > Vulkan formats? The only exception here should be sRGB formats. Where
> > did you get the information from?
>
> This is what upstream dfdutils does [1]. Can you explain why you think
> it should be undefined instead of linear?

The channels have no meaning. You can put whatever you want in there.
It doesn't have to be linear, it doesn't have to be colors and
especially not colors with specific primaries. It's only when it's
used to form an image that the TF and primaries are known. Vulkan
specifically requires you to explicitly provide this information to
the WSI and YCC samplers (generally everywhere where knowing them is
required) and never assumes that certain pixel formats imply certain
TFs and primaries (exception being the sRGB variants).


(See also 
https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#_issues_26,
Q 23)

The problem here seems to be that the Data Format spec describes more
than the pixel format. If you want to share an image, the TF and
primaries are essential but they are not an inherent part of the pixel
format of the image. So yeah, I think what dfdutils does is...
probably not wrong but not what you're after.

>
> I was wondering what to do for DRM formats regarding these. I think it
> would be worthwhile to do like Vulkan: set TF = linear, primaries =
> BT.709, pre-multiplied alpha = yes. These are the things KMS assume
> when there is no override (ie, when there is no KMS property saying
> otherwise).

Please no. All undefined is absolutely the right thing to do. Adding
any more meaning to pixel formats is a horrible idea. The KMS
properties are also not an override, they describe the image and the
description has default values.

>
> [1]: 
> https://github.com/KhronosGroup/dfdutils/blob/5cd41cbdf63e80b00c085c6906a1152709e4c0f2/createdfd.c#L47
>