[PATCH] linux-dmabuf: clarify DRM_FORMAT_MOD_INVALID
olvaffe at gmail.com
Fri Apr 12 17:50:49 UTC 2019
Moving the discussion to this patch...
This patch clarifies how implicit modifier can be supported, modelling
after Weston's behavior. I can see three options
1. DRM_FORMAT_MOD_INVALID means implicit modifier, and is always allowed
in buffer creation
2. DRM_FORMAT_MOD_INVALID means implicit modifier, and a modifier event of
the value must be sent to indicate buffer creation with implicit modifier
3. DRM_FORMAT_MOD_INVALID is invalid and there is no implicit modifier
This patch picks option 1.
Option 3 makes legacy support impossible, and in turn makes wl_drm
deprecation take longer.
I've been thinking about moving away from implicit modifier as well so
option 2 might be a good compromise. The protocol is also more consistent
in that one can create a buffer with a format/modifier pair only when the
pair is advertised via the modifier event.
On Tue, Apr 9, 2019 at 3:23 PM Chia-I Wu <olvaffe at gmail.com> wrote:
> Talked with Daniel offline. I sent a different version to revive the
> format event.
> On Mon, Apr 1, 2019 at 10:41 AM Chia-I Wu <olvaffe at gmail.com> wrote:
>> DRM_FORMAT_MOD_INVALID means to derive the modifier from the dmabuf.
>> Signed-off-by: Chia-I Wu <olvaffe at gmail.com>
>> .../linux-dmabuf/linux-dmabuf-unstable-v1.xml | 15 ++++++++++++++-
>> 1 file changed, 14 insertions(+), 1 deletion(-)
>> diff --git a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> index 154afe2..7c76441 100644
>> --- a/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> +++ b/unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml
>> @@ -28,6 +28,7 @@
>> <description summary="factory for creating dmabuf-based wl_buffers">
>> Following the interfaces from:
>> and the Linux DRM sub-system's AddFb2 ioctl.
>> This interface offers ways to create generic dmabuf-based
>> @@ -129,8 +130,13 @@
>> binds to this interface. A roundtrip after binding guarantees
>> the client has received all supported format-modifier pairs.
>> + For each supported format, DRM_FORMAT_MOD_INVALID (that is,
>> + modifier_hi == 0x00ffffff and modifier_lo == 0xffffffff) is
>> + and may not be sent.
> For option 2, this can be removed.
> For the definition of the format and modifier codes, see the
>> - zwp_linux_buffer_params_v1::create request.
>> + zwp_linux_buffer_params_v1::create and
>> + requests.
>> <arg name="format" type="uint" summary="DRM_FORMAT code"/>
>> <arg name="modifier_hi" type="uint"
>> @@ -200,6 +206,13 @@
>> This request raises the PLANE_IDX error if plane_idx is too
>> The error PLANE_SET is raised if attempting to set a plane that
>> was already set.
>> + Note that DRM_FORMAT_MOD_INVALID (that is, modifier_hi ==
>> + and modifier_lo == 0xffffffff) is always allowed and has a
>> + meaning. It indicates that the modifier is derived from the
>> dmabuf fd
>> + rather than explicitly specified. This use is discouraged and
>> may not
>> + work if the dmabuf is imported to a different device than the
>> + that allocated it.
> For option 2, this can be moved to where the modifier event is defined.
The wording needs to be changed.
>> <arg name="fd" type="fd" summary="dmabuf fd"/>
>> <arg name="plane_idx" type="uint" summary="plane index"/>
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the wayland-devel