Re: [PATCH weston v5 00/36] Head-based output configuration API a.k.a clone mode infrastructure
On Fri, Dec 15, 2017 at 2:27 AM, Pekka Paalanen wrote: > On Thu, 14 Dec 2017 10:11:32 -0500 > Alex Deucher wrote: > >> On Thu, Dec 14, 2017 at 6:40 AM, Pekka Paalanen wrote: >> > From: Pekka Paalanen >> > >> > Hi all, >> > >> > this is v5 (to match the numbering of my public branches) of the libweston >> > user >> > facing API and infrastructure for supporting shared-CRTC clone mode. >> > >> > Previous submission with rationale: >> > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html >> > >> > Design document: >> > https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/ >> > >> > The goal: >> > https://phabricator.freedesktop.org/T7727 >> >> FWIW, at least with the DC modesetting code in amdgpu, we can >> synchronize multiple crtcs to the same timing when the monitors all >> support the same mode timing or with monitors that have different >> timings using variable length blanking periods on freesync capable >> monitors. > > Hi Alex, > > that's cool. How does userspace take advantage of that, how do you > configure KMS/atomic to make use of that? Is it supported through > legacy KMS (non-atomic) as well? the driver automatically syncs all heads that it can at modeset time I think. > > Does it involve things like the driver stealing an unused CRTC for each > additional clone? No, there is logic in the gpu to sync the timing of multiple crtcs. You just need 1 crtc per display. > > The feature would fit perfectly under the "shared-CRTC clone mode" from > libweston API point of view, even though it's not actually a single > shared CRTC. > > > Thanks, > pq > >> >> >> Alex >> >> > >> > Changes in v5 compared to v3 are minor: >> > - "libweston: properly orphan wl_output resources" is new. >> > - Removal of wl_output global, when a head is detached from an enabled >> > output. >> > - Print "Detected a monitor change" only for enabled heads. >> > >> > You can find this series in the branch: >> > https://gitlab.collabora.com/pq/weston/commits/clonemode-user-API-5 >> > >> > I went through the same testing procedure as with v3, the previous >> > submission. >> > >> > >> > However, the interesting bits are in the branch: >> > https://gitlab.collabora.com/pq/weston/commits/clonemode-4 >> > >> > As new things compared to clonemode-user-API-2, that one contains: >> > - support for configuring clone mode in weston.ini >> > - main.c implementation to configure a clode using the new API >> > - desktop-shell enhancements to avoid redundant panel and background >> > surfaces >> > in clone mode >> > - hooking up custom data to weston_output via a new user-side destroy >> > signal >> > - naming outputs freely >> > - DRM-backend support for shared-CRTC clone mode >> > - video mode list merging in the DRM-backend >> > >> > The shared-CRTC clone mode has been tested to work on an i.MX6 device. >> > Unfortunately it seems that PC hardware that would support it is becoming >> > scarce AFAIU. >> > >> > Most of the patches in clonemode-4 depend on the atomic modesetting series >> > and >> > can therefore be submitted only after that one. >> > ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[ANNOUNCE] libxkbcommon 0.8.0
libxkbcommon 0.8.0
==
- Added xkb_keysym_to_{upper,lower} to perform case-conversion directly on
keysyms. This is useful in some odd cases, but working with the Unicode
representations should be preferred when possible.
- Added Unicode conversion rules for the signifblank and permille keysyms.
- Fixed a bug in the parsing of XKB key type definitions where the number
of levels were determined by the number of level *names*. Keymaps which
omit level names were hence miscompiled.
This regressed in version 0.4.3. Keymaps from xkeyboard-config were not
affected since they don't omit level names.
- New API:
xkb_keysym_to_upper()
xkb_keysym_to_lower()
Tarball:
git tag: xkbcommon-0.8.0
https://xkbcommon.org/download/libxkbcommon-0.8.0.tar.xz
MD5:7d0e4c4a137d0ac45bf6b328c84c3a81 libxkbcommon-0.8.0.tar.xz
SHA1: 2bdd5871e5e76f2fc427911f137aa46e91abbcf3 libxkbcommon-0.8.0.tar.xz
SHA256: e829265db04e0aebfb0591b6dc3377b64599558167846c3f5ee5c5e53641fe6d
libxkbcommon-0.8.0.tar.xz
Ran
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] linux-dmabuf: send deprecated format events
On Fri, 2017-12-15 at 10:51 +, Daniel Stone wrote:
> Hi Philipp,
>
> On 15 December 2017 at 10:46, Philipp Zabel wrote:
> > On Fri, 2017-12-15 at 09:46 +, Daniel Stone wrote:
> > > On 15 December 2017 at 09:25, Philipp Zabel
> > > wrote:
> > > > Send format events instead of the modifier event, if the client binds on
> > > > a protocol version before version 3, skipping formats that only support
> > > > non-linear modifiers.
> > >
> > > Thanks for this! Could I please persuade you to take on one additional
> > > change though?
> > >
> > > Specifically, if has_dmabuf_import_modifiers is not supported,
> > > gl-renderer will return 0 for num_formats. In this case, it seems like
> > > we should send a conservative list: ARGB, XRGB, and maybe
> > > speculatively the YUV formats we have hardcoded conversions for
> > > (provided we have R8/RG8 support, cf. the patches from Arnaud).
> >
> > Should we modify gl_renderer_query_dmabuf_formats to return that list of
> > hardcoded formats if has_dmabuf_import_modifiers is not supported?
>
> That was exactly what I had in mind.
>
> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
I haven't tested this yet with has_dmabuf_import_modifiers disabled, but
looking at this, I wonder whether this is the right thing to do.
If has_dmabuf_import_modifiers is set and the driver reports R8/RG88 in
query_dmabuf_formats, shouldn't we add the YUV formats as well?
--8<--
gl-renderer: return conservative format list if dmabuf import modifiers
unsupported
If the EGL_EXT_image_dma_buf_import_modifiers extension is not
supported, let gl_renderer_query_dmabuf_formats return a hardcoded
fallback list. That list contains ARGB, XRGB, and if the
GL_EXT_texture_rg extension is supported, YUYV, NV12, YUV420, and
YUV444.
Signed-off-by: Philipp Zabel
diff --git a/libweston/gl-renderer.c b/libweston/gl-renderer.c
index abf556f0..ee31a86d 100644
--- a/libweston/gl-renderer.c
+++ b/libweston/gl-renderer.c
@@ -2088,14 +2088,23 @@ gl_renderer_query_dmabuf_formats(struct
weston_compositor *wc,
int **formats, int *num_formats)
{
struct gl_renderer *gr = get_renderer(wc);
+ int fallback_formats[] = {
+ DRM_FORMAT_ARGB,
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_YUYV,
+ DRM_FORMAT_NV12,
+ DRM_FORMAT_YUV420,
+ DRM_FORMAT_YUV444,
+ };
+ bool fallback = false;
EGLint num;
assert(gr->has_dmabuf_import);
if (!gr->has_dmabuf_import_modifiers ||
!gr->query_dmabuf_formats(gr->egl_display, 0, NULL, &num)) {
- *num_formats = 0;
- return;
+ num = gr->has_gl_texture_rg ? ARRAY_LENGTH(fallback_formats) :
2;
+ fallback = true;
}
*formats = calloc(num, sizeof(int));
@@ -2103,6 +2112,13 @@ gl_renderer_query_dmabuf_formats(struct
weston_compositor *wc,
*num_formats = 0;
return;
}
+
+ if (fallback) {
+ memcpy(formats, fallback_formats, num * sizeof(int));
+ *num_formats = num;
+ return;
+ }
+
if (!gr->query_dmabuf_formats(gr->egl_display, num, *formats, &num)) {
*num_formats = 0;
free(*formats);
-->8--
regards
Philipp
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[RFC PATCH xserver] xwayland: avoid race condition on new keymap
When the Wayland compositor notifies of a new keymap, for the first X11 client using the keyboard, the last slave keyboard used might still not be set (i.e. “lastSlave” is still NULL). As a result, the new keymap is not applied, and the first X11 window will have the wrong keymap set initially. Apply the new keymap to the master keyboard as long as there's one. Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=791383 Signed-off-by: Olivier Fourdan --- Note: screencast of the problem here: https://bugzilla.gnome.org/attachment.cgi?id=365231 “RFC” because that fixes the issue but there might be better ways to avoid the problem? hw/xwayland/xwayland-input.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-input.c index 439903032..c613690cd 100644 --- a/hw/xwayland/xwayland-input.c +++ b/hw/xwayland/xwayland-input.c @@ -710,7 +710,7 @@ keyboard_handle_keymap(void *data, struct wl_keyboard *keyboard, XkbDeviceApplyKeymap(xwl_seat->keyboard, xkb); master = GetMaster(xwl_seat->keyboard, MASTER_KEYBOARD); -if (master && master->lastSlave == xwl_seat->keyboard) +if (master) XkbDeviceApplyKeymap(master, xkb); XkbFreeKeyboard(xkb, XkbAllComponentsMask, TRUE); -- 2.14.3 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] rdp compositor: add a man page and add links to that page
--- Makefile.am| 5 +++ man/weston-rdp.man | 92 ++ man/weston.man | 13 3 files changed, 110 insertions(+) create mode 100644 man/weston-rdp.man diff --git a/Makefile.am b/Makefile.am index 7adc625..f67e693 100644 --- a/Makefile.am +++ b/Makefile.am @@ -1563,6 +1563,10 @@ if ENABLE_DRM_COMPOSITOR man_MANS += weston-drm.7 endif +if ENABLE_RDP_COMPOSITOR +man_MANS += weston-rdp.7 +endif + MAN_SUBSTS = \ -e 's|__weston_native_backend__|$(WESTON_NATIVE_BACKEND)|g' \ -e 's|__weston_modules_dir__|$(pkglibdir)|g'\ @@ -1577,6 +1581,7 @@ SUFFIXES = .1 .5 .7 .man EXTRA_DIST += \ man/weston.man \ man/weston-drm.man \ + man/weston-rdp.man \ man/weston.ini.man CLEANFILES += $(man_MANS) diff --git a/man/weston-rdp.man b/man/weston-rdp.man new file mode 100644 index 000..0916c8d --- /dev/null +++ b/man/weston-rdp.man @@ -0,0 +1,92 @@ +.TH WESTON-RDP 7 "2017-12-14" "Weston __version__" +.SH NAME +weston-rdp \- the RDP backend for Weston +.SH SYNOPSIS +.B weston --backend=rdp-backend.so +. +.\" *** +.SH DESCRIPTION +The RDP backend allows to run a +.B weston +environment without the need of specific graphic hardware, or input devices. Users can interact with +.B weston +only by connecting using the RDP protocol. + +The RDP backend uses FreeRDP to implement the RDP part, it acts as a RDP server +listening for incoming connections. It supports different codecs for encoding the +graphical content. Depending on what is supported by the RDP client, the backend will +encode images using remoteFx codec, NS codec or will fallback to raw bitmapUpdate. + +On the security part, the backend supports RDP security or TLS, keys and certificates +must be provided to the backend depending on which kind of security is requested. The RDP +backend will announce security options based on which files have been given. + +The RDP backend is multi-seat aware, so if two clients connect on the backend, +they will get their own seat. + +.\" *** +.SH OPTIONS +. +When the RDP backend is loaded, +.B weston +will understand the following additional command line options. +.TP +.B \-\-address\fR=\fIaddress\fR +The IP address on which the RDP backend will listen for RDP connections. By +default it listens on 0.0.0.0. +.TP +\fB\-\-port\fR=\fIport\fR +The TCP port to listen on for connections, it defaults to 3389. +.TP +\fB\-\-no-clients-resize +By default when a client connects on the RDP backend, it will instruct weston to +resize to the dimensions of the client's announced resolution. When this option is +set, weston will force the client to resize to its own resolution. +.TP +\fB\-\-rdp4\-key\fR=\fIfile\fR +The file containing the RSA key for doing RDP security. As RDP security is known +to be insecure, this option should be avoided in production. +.TP +\fB\-\-rdp\-tls\-key\fR=\fIfile\fR +The file containing the key for doing TLS security. To have TLS security you also need +to ship a file containing a certificate. +.TP +\fB\-\-rdp\-tls\-cert\fR=\fIfile\fR +The file containing the certificate for doing TLS security. To have TLS security you also need +to ship a key file. + + +.\" *** +.SH Generating cryptographic material for the RDP backend +. +To generate a key file to use for RDP security, you need the +.BR winpr-makecert +utility shipped with FreeRDP: + +.nf +$ winpr-makecert -rdp -silent -n rdp-security +.fi + +This will create a rdp-security.key file. + + +You can generate a key and certificate file to use with TLS security using a typical +.B openssl +invocations: + +.nf +$ openssl genrsa -out tls.key 2048 +Generating RSA private key, 2048 bit long modulus +[...] +$ openssl req -new -key tls.key -out tls.csr +[...] +$ openssl x509 -req -days 365 -signkey tls.key -in tls.csr -out tls.crt +[...] +.fi + +You will get the tls.key and tls.crt files to use with the RDP backend. +. +.\" *** +.SH "SEE ALSO" +.BR weston (1) +.\".BR weston.ini (5) diff --git a/man/weston.man b/man/weston.man index cd53df6..7c3416c 100644 --- a/man/weston.man +++ b/man/weston.man @@ -46,6 +46,13 @@ the parent server. The X11 backend runs on an X server. Each Weston output becomes an X window. This is a cheap way to test multi-monitor support of a Wayland shell, desktop, or applications. +.TP +.I rdp-backend.so +The RDP backend runs in memory without the need of graphical hardware. Access +to the desktop is done by using the RDP protocol. Each connecting +client has its own seat making it a cheap way to test multi
Re: [PATCH] linux-dmabuf: send deprecated format events
Hi Philipp, On 15 December 2017 at 10:46, Philipp Zabel wrote: > On Fri, 2017-12-15 at 09:46 +, Daniel Stone wrote: >> On 15 December 2017 at 09:25, Philipp Zabel wrote: >> > Send format events instead of the modifier event, if the client binds on >> > a protocol version before version 3, skipping formats that only support >> > non-linear modifiers. >> >> Thanks for this! Could I please persuade you to take on one additional >> change though? >> >> Specifically, if has_dmabuf_import_modifiers is not supported, >> gl-renderer will return 0 for num_formats. In this case, it seems like >> we should send a conservative list: ARGB, XRGB, and maybe >> speculatively the YUV formats we have hardcoded conversions for >> (provided we have R8/RG8 support, cf. the patches from Arnaud). > > Should we modify gl_renderer_query_dmabuf_formats to return that list of > hardcoded formats if has_dmabuf_import_modifiers is not supported? That was exactly what I had in mind. Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] linux-dmabuf: send deprecated format events
Hi Daniel, On Fri, 2017-12-15 at 09:46 +, Daniel Stone wrote: > Hi Michael and Philipp, > > On 15 December 2017 at 09:25, Philipp Zabel wrote: > > Although the format event is deprecated, some clients, especially the > > GStreamer waylandsink, only support zwp_linux_dmabuf_v1 version 1 and > > require the deprecated format event. > > > > Send format events instead of the modifier event, if the client binds on > > a protocol version before version 3, skipping formats that only support > > non-linear modifiers. > > Thanks for this! Could I please persuade you to take on one additional > change though? > > Specifically, if has_dmabuf_import_modifiers is not supported, > gl-renderer will return 0 for num_formats. In this case, it seems like > we should send a conservative list: ARGB, XRGB, and maybe > speculatively the YUV formats we have hardcoded conversions for > (provided we have R8/RG8 support, cf. the patches from Arnaud). Should we modify gl_renderer_query_dmabuf_formats to return that list of hardcoded formats if has_dmabuf_import_modifiers is not supported? regards Philipp ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH weston v5 00/36] Head-based output configuration API a.k.a clone mode infrastructure
On Thu, 14 Dec 2017 13:40:37 +0200 Pekka Paalanen wrote: > From: Pekka Paalanen > > Hi all, > > this is v5 (to match the numbering of my public branches) of the libweston > user > facing API and infrastructure for supporting shared-CRTC clone mode. > > Previous submission with rationale: > https://lists.freedesktop.org/archives/wayland-devel/2017-October/035604.html > > Design document: > https://phabricator.freedesktop.org/w/wayland/weston/atomic-output-config/ > > The goal: > https://phabricator.freedesktop.org/T7727 > > Changes in v5 compared to v3 are minor: > - "libweston: properly orphan wl_output resources" is new. > - Removal of wl_output global, when a head is detached from an enabled output. > - Print "Detected a monitor change" only for enabled heads. > > You can find this series in the branch: > https://gitlab.collabora.com/pq/weston/commits/clonemode-user-API-5 > > I went through the same testing procedure as with v3, the previous submission. Hi, thanks to the weston-rdp man page patch on the list, I was finally able to test the RDP-backend with v5 series and it seems to work fine. Thanks, pq pgpWDSehNQjTo.pgp Description: OpenPGP digital signature ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [PATCH] rdp compositor: add a man page
On Thu, 14 Dec 2017 13:51:11 +0100 David Fort wrote: > --- > Makefile.am| 5 +++ > man/weston-rdp.man | 92 > ++ > 2 files changed, 97 insertions(+) > create mode 100644 man/weston-rdp.man > > diff --git a/Makefile.am b/Makefile.am > index 7adc625..f67e693 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -1563,6 +1563,10 @@ if ENABLE_DRM_COMPOSITOR > man_MANS += weston-drm.7 > endif > > +if ENABLE_RDP_COMPOSITOR > +man_MANS += weston-rdp.7 > +endif > + > MAN_SUBSTS = \ > -e 's|__weston_native_backend__|$(WESTON_NATIVE_BACKEND)|g' \ > -e 's|__weston_modules_dir__|$(pkglibdir)|g'\ > @@ -1577,6 +1581,7 @@ SUFFIXES = .1 .5 .7 .man > EXTRA_DIST +=\ > man/weston.man \ > man/weston-drm.man \ > + man/weston-rdp.man \ > man/weston.ini.man > > CLEANFILES += $(man_MANS) > diff --git a/man/weston-rdp.man b/man/weston-rdp.man > new file mode 100644 > index 000..88c795a > --- /dev/null > +++ b/man/weston-rdp.man > @@ -0,0 +1,92 @@ > +.TH WESTON-RDP 7 "2017-12-14" "Weston __version__" > +.SH NAME > +weston-rdp \- the RDP backend for Weston > +.SH SYNOPSIS > +.B weston --backend=rdp-backend.so > +. > +.\" *** > +.SH DESCRIPTION > +The RDP backend allows to run a > +.B weston > +environment without the need of specific graphic hardware, or input devices. > Users can interact with > +.B weston > +only by connecting using the RDP protocol. > + > +The RDP backend uses FreeRDP to implement the RDP part, it acts as a RDP > server > +listening for incoming connections. It supports different codecs for > encoding the > +graphical content. Depending on what is supported by the RDP client, the > backend will > +encode images using remoteFx codec, NS codec or will fallback to raw > bitmapUpdate. > + > +On the security part, the backend supports RDP security or TLS, keys and > certificates > +must be provided to the backend depending on which kind of security is > requested. The RDP > +backend will announced security options based on which files have been given. s/announced/announce/ ? > + > +The RDP backend is multi-seat aware, so if two clients connect on the > backend, > +they will get their own seat. "each will get its own logical seat"? This seems like a nice way to test multi-seat, btw. :-) > + > +.\" *** > +.SH OPTIONS > +. > +When the RDP backend is loaded, > +.B weston > +will understand the following additional command line options. > +.TP > +.B \-\-address\fR=\fIaddress\fR > +The IP address on which the RDP backend will listen for RDP connections. By > +default it listens on 0.0.0.0. > +.TP > +\fB\-\-port\fR=\fIport\fR > +The TCP port to listen on for connections, it defaults to 3389. > +.TP > +\fB\-\-no-clients-resize > +By default when a client connects on the RDP backend, it will instruct > weston to > +resize to the dimensions of the client's announced resolution. When this > option is > +set, weston will force the client to resize to its own resolution. > +.TP > +\fB\-\-rdp4\-key\fR=\fIfile\fR > +The file containing the RSA key for doing RDP security. As RDP security is > known > +to be insecure, this option should be avoided in production. > +.TP > +\fB\-\-rdp\-tls\-key\fR=\fIfile\fR > +The file containing the key for doing TLS security. To have TLS security you > also need > +to ship a file containing a certificate. > +.TP > +\fB\-\-rdp\-tls\-cert\fR=\fIfile\fR > +The file containing the certificate for doing TLS security. To have TLS > security you also need > +to ship a key file. > + > + > +.\" *** > +.SH Generating cryptographic material for the RDP backend > +. > +To generate a key file to use for RDP security, you need the > +.BR winpr-makecert > +utility shipped with FreeRDP: > + > +.nf > +$ winpr-makecert -rdp -silent -n rdp-security > +.fi > + > +This will create a rdp-security.key file. > + > + > +You can generate a key and certificate file to use with TLS security using a > typical > +.B openssl > +invocations: > + > +.nf > +$ openssl genrsa -out tls.key 2048 > +Generating RSA private key, 2048 bit long modulus > +[...] > +$ openssl req -new -key tls.key -out tls.csr > +[...] > +$ openssl x509 -req -days 365 -signkey tls.key -in tls.csr -out tls.crt > +[...] > +.fi > + > +You will get the tls.key and tls.crt files to use with the RDP backend. Nice, I went through these commands and I can run it! :-) > +. > +.\" *** > +.SH "SEE ALSO" > +.BR weston (1) > +.\".BR weston.ini (5) You could also modify weston.man to include a reference to this man page as w
Re: [PATCH] linux-dmabuf: send deprecated format events
Hi Michael and Philipp, On 15 December 2017 at 09:25, Philipp Zabel wrote: > Although the format event is deprecated, some clients, especially the > GStreamer waylandsink, only support zwp_linux_dmabuf_v1 version 1 and > require the deprecated format event. > > Send format events instead of the modifier event, if the client binds on > a protocol version before version 3, skipping formats that only support > non-linear modifiers. Thanks for this! Could I please persuade you to take on one additional change though? Specifically, if has_dmabuf_import_modifiers is not supported, gl-renderer will return 0 for num_formats. In this case, it seems like we should send a conservative list: ARGB, XRGB, and maybe speculatively the YUV formats we have hardcoded conversions for (provided we have R8/RG8 support, cf. the patches from Arnaud). Cheers, Daniel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
[PATCH] linux-dmabuf: send deprecated format events
From: Michael Tretter
Although the format event is deprecated, some clients, especially the
GStreamer waylandsink, only support zwp_linux_dmabuf_v1 version 1 and
require the deprecated format event.
Send format events instead of the modifier event, if the client binds on
a protocol version before version 3, skipping formats that only support
non-linear modifiers.
Signed-off-by: Michael Tretter
Signed-off-by: Philipp Zabel
---
libweston/linux-dmabuf.c | 19 ---
libweston/linux-dmabuf.h | 3 +++
2 files changed, 15 insertions(+), 7 deletions(-)
diff --git a/libweston/linux-dmabuf.c b/libweston/linux-dmabuf.c
index d81b63d5..ccdcfb08 100644
--- a/libweston/linux-dmabuf.c
+++ b/libweston/linux-dmabuf.c
@@ -483,8 +483,6 @@ bind_linux_dmabuf(struct wl_client *client,
wl_resource_set_implementation(resource, &linux_dmabuf_implementation,
compositor, NULL);
- if (version < ZWP_LINUX_DMABUF_V1_MODIFIER_SINCE_VERSION)
- return;
/*
* Use EGL_EXT_image_dma_buf_import_modifiers to query and advertise
* format/modifier codes.
@@ -505,11 +503,18 @@ bind_linux_dmabuf(struct wl_client *client,
modifiers = &modifier_invalid;
}
for (j = 0; j < num_modifiers; j++) {
- uint32_t modifier_lo = modifiers[j] & 0x;
- uint32_t modifier_hi = modifiers[j] >> 32;
- zwp_linux_dmabuf_v1_send_modifier(resource, formats[i],
- modifier_hi,
- modifier_lo);
+ if (version >=
ZWP_LINUX_DMABUF_V1_MODIFIER_SINCE_VERSION) {
+ uint32_t modifier_lo = modifiers[j] &
0x;
+ uint32_t modifier_hi = modifiers[j] >> 32;
+ zwp_linux_dmabuf_v1_send_modifier(resource,
+ formats[i],
+ modifier_hi,
+ modifier_lo);
+ } else if (modifiers[j] == DRM_FORMAT_MOD_LINEAR ||
+ modifiers == &modifier_invalid) {
+ zwp_linux_dmabuf_v1_send_format(resource,
+ formats[i]);
+ }
}
if (modifiers != &modifier_invalid)
free(modifiers);
diff --git a/libweston/linux-dmabuf.h b/libweston/linux-dmabuf.h
index f4ab52cb..dbeda660 100644
--- a/libweston/linux-dmabuf.h
+++ b/libweston/linux-dmabuf.h
@@ -32,6 +32,9 @@
#ifndef DRM_FORMAT_MOD_INVALID
#define DRM_FORMAT_MOD_INVALID ((1ULL<<56) - 1)
#endif
+#ifndef DRM_FORMAT_MOD_LINEAR
+#define DRM_FORMAT_MOD_LINEAR 0
+#endif
struct linux_dmabuf_buffer;
typedef void (*dmabuf_user_data_destroy_func)(
--
2.11.0
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel
