Re: Protocol backwards compatibility requirements?

[Simon Ser]

Hi,

On Monday, April 13, 2020 1:59 AM, Peter Hutterer  
wrote:
> Hi all,
>
> This is request for comments on the exact requirements for protocol
> backwards compatibility for clients binding to new versions of an interface.
> Reason for this are the high-resolution wheel scrolling patches:
> https://gitlab.freedesktop.org/wayland/wayland/-/merge_requests/72
>
> Specifically, the question is: do we **change** protocol elements or
> behaviour as the interface versions increase? A few random examples:

What we can't do is:

- Change existing messages' signature
- Completely remove a message

> - event wl_foo.bar introduced in version N sends a wl_fixed in
>   surface coordinates. version N+1 changes this to a normalized
>   [-1, +1] range.

Argument types can't be changed. This would be a breaking change for the
generated code, we can't do that.

> - request wl_foo.bar introduced in version N takes an int. version N+1
>   changes wl_foo.bar to take a wl_fixed and an enum.

Ditto.

> - request wl_foo.bar introduced in version N guaranteed to generate a single
>   event wl_foo.baz. if the client binds to version N+1 that event may be
>   sent zero, one or multiple times.

This is fine.

> I think these examples cover a wide-enough range of the possible changes.
>
> My assumption was that we only ever add new requests/events but never change
> existing behaviour. So wl_foo.bar introduced in version N will always have
> the same behaviour for any interface N+m.

We can change existing requests' behaviour. This has already been done a
number of times, see e.g. wl_data_offer.accept or xdg_output.description.

Clients should always have a max-version, ie. they should never blindly bind
to the compositor's version.

What is also fine is marking a message as "deprecated from version N". Such a
message wouldn't be sent anymore starting from this version.

> I've seen some pushback for above linked patchset because it gets
> complicated and suggestions to just change the current interface.
> The obvious advantage is being able to clean up any mess in the protocol.
>
> The disadvantages are the breakage of backwards compatibility with older
> versions. You're effectively forcing every compositor/client to change the
> code based on the version number, even where it's not actually needed. Or,
> IOW, a client may want a new feature in N+2 but now needs to implement all
> changes from N+1 since they may change the behaviour significantly.

Indeed.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

RE: Getting Weston to use DRM/KMS planes

[Wohlmuth, Oliver]

Hi Daniel, all,

I thought I provide a short update on this in case someone else comes across 
this:
The udmabuf approach works fine with SW rendering, but fails when importing the 
buffer into KMS. KMS requires one chunk of physical contiguous memory, but the 
buffer I created via memfd_create() is scattered in 4kbyte chunks. After 
knowing that a dmabuf can be imported into KMS, I realized that a KMS buffer 
can also be exported as dmabuf. Therefore, I do now allocate a KMS buffer and 
export it as dmabuf via PRIME. With this, using the buffer for pixman rendering 
and directly as KMS plane works fine. 

@Daniel: Thanks again for your help!

Regards,
Oliver  

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Wohlmuth, Oliver
Sent: Wednesday, March 25, 2020 1:38 PM
To: Daniel Stone 
Cc: wayland-devel@lists.freedesktop.org
Subject: RE: Getting Weston to use DRM/KMS planes

Hi Daniel,

Many thanks for your detailed explanation. This helps a lot! I will look into 
your suggested approach of using udmabuf.

Regards,
Oliver

-Original Message-
From: wayland-devel [mailto:wayland-devel-boun...@lists.freedesktop.org] On 
Behalf Of Daniel Stone
Sent: Wednesday, March 25, 2020 12:04 PM
To: Wohlmuth, Oliver 
Cc: wayland-devel@lists.freedesktop.org
Subject: Re: Getting Weston to use DRM/KMS planes

Hi Oliver,

On Wed, 25 Mar 2020 at 10:31, Wohlmuth, Oliver  
wrote:
> I just started to work with Wayland/Weston, so please forgive me if I ask 
> silly questions.
>
> I’m running Weston (8.0.0) on a custom ARM SoC using the DRM backend. 
> As the OpenGL driver is not (yet) adapted for Wayland, I'm running Weston 
> using the '--use-pixman' option.
> This works fine so far.
>
> As our DRM/KMS driver supports several HW planes, I was debugging into 
> the Weston code trying to understand how Weston makes use of these HW 
> planes (or what needs to be done to get Weston use the HW planes). If I 
> understand the code correctly:
>
> drm_fb_get_from_view()
> {
> ...
> if (wl_shm_buffer_get(buffer->resource))
> return NULL;
> ...
> }
>
> Weston will never use HW planes for wl_shm_buffer, only for GBM or 
> dmabuf type buffer it will be used.
>
>
>
> - Is this correct? What is the reason for this?

That's correct. The reason is that we need to be able to get a KMS framebuffer 
object with the pixel content from the client buffer in it. Effectively, the 
only way to import client content into a KMS framebuffer is via dmabuf; KMS has 
no method of creating framebuffers from an arbitrary pointer to user memory. 
And we need a framebuffer object in order to display anything on a plane.

> - Any suggestions how to get HW planes used without OpenGL rendering?
>
>   Currently I think of patching Weston or implement a Weston client that
>   uses dmabuf buffer. Any hint is appreciated that puts me on the most
>   promising path.

There is no easy out-of-the-box path. The first place to start would be to 
patch a client to allocate a dmabuf through the udmabuf kernel API (the one in 
the mainline kernel tree, not the external module living on GitHub), or the 
vgem driver.

Once you've done that, you will very quickly notice that Weston doesn't 
actually support the dmabuf extension when using the Pixman renderer. This 
would be possible to implement by implementing the import_dmabuf, 
query_dmabuf_formats, and query_dmabuf_modifiers hooks.
You probably only want to declare support the ARGB/XRGB formats and the 
LINEAR modifier. For import_dmabuf, you would want to call the 
DMA_BUF_IOCTL_SYNC call on the provided FD, mmap the dmabuf, then call 
pixman_image_create_bits_no_clear() to obtain a pixman_image which the renderer 
can use to source from the dmabuf's content.

The reason we require the renderer to support dmabuf as well as the backend is 
for fallback: in case we can't display the client content on a KMS plane (which 
is not guaranteed, as the driver can reject planes for any reason or 
limitation), we need to be able to use the renderer as a fallback to show the 
content.

Alternately, if your SoC has an Arm Mali GPU, you can use the Panfrost driver 
available in the upstream Linux kernel and Mesa GL implementation, which fully 
supports dmabuf/Wayland/GBM/etc.

Hope that helps.

Cheers,
Daniel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel