Re: libweston as a DRM lease lessee

On 1/02/21 10:19 pm, Damian Hobson-Garcia wrote: Hi all, I am working on adding DRM lease support to a libweston based compositor. The compositor will be a client (lessee) that will display output to a DRM lease that is created by another (lessor) process, so this is kind of the opposite

Re: Best practices for client side buffer management

On 19/06/20 3:24 pm, Brad Robinson wrote: Hi All, I'm fairly new to Wayland and Linux GUI programming in general, but doing some experiments to figure out how to integrate it into my custom UI toolkit library and have a couple of questions about client side buffer management. Firstly, this

Re: Best practices for saving and restoring window layout

On 5/06/20 10:09 pm, Pekka Paalanen wrote: On Fri, 5 Jun 2020 02:06:00 +1000 Brad Robinson wrote: Hi All, First post here... I'm looking into porting an existing UI library to Gtk+ and I'm struggling to solve a couple of problems related to window positioning when using Wayland as the

Re: Protocol backwards compatibility requirements?

On 21/04/20 12:57 pm, Christopher James Halse Rogers wrote: On Mon, Apr 20, 2020 at 15:05, Pekka Paalanen wrote: On Thu, 16 Apr 2020 17:47:56 +1000 Christopher James Halse Rogers wrote:  On Wed, Apr 15, 2020 at 14:27, Simon Ser wrote:  > Hi,  >  > On Monday, April 13, 2020 1:59 AM, Peter

Re: linux-dmabuf and eglBindWaylandDisplayWl

On 10/04/20 10:34 am, Matt Hoosier wrote: On Thu, Apr 9, 2020 at 2:51 PM Simon Ser > wrote: On Thursday, April 9, 2020 9:41 PM, Matt Hoosier mailto:matt.hoos...@gmail.com>> wrote: > If I remember correctly, I've read various messages on the list

Re: Chrome Remote Desktop and Wayland

On 8/04/20 4:04 pm, Erik Jensen wrote: Hello, I'm currently looking into how best to continue supporting Linux for Chrome Remote Desktop given the current direction of development for graphical sessions on Linux, and would like some community feedback as to the best path forward. Chrome Remote

Re: [PATCH wayland-protocols v7] Add zwp_linux_explicit_synchronization_v1

On 4/02/20 10:16 pm, Pekka Paalanen wrote: On Mon, 3 Feb 2020 23:26:55 -0600 Jason Ekstrand wrote: Sorry to drag up ancient threads, but what's the status of this? I see rumors that it's in Weston. Is it stable? Is it implemented anywhere else? It'd be great, for the sake of Vulkan, if we

Re: wl_surface/wl_subsurface composition

On 11/12/19 8:46 pm, Martin Stransky wrote: Hi guys, while solving a Firefox Wayland bug [1] I wonder if there's any composition between a surface and a subsurface on compositor side (namely mutter) when the subsurface area is subset of the surface and the surface is set as opaque. Both

Re: libwayland surface coordinate question

On 22/11/19 2:40 pm, Ken C wrote: I am just starting out with libweston and have a beginner question regarding surface/view coordinates. I am looking to implement something along the lines of issue #277 on gitlab[1], "New shell plugin for single-app usecases". I have swapped out

Re: Do I need wl_frame_callback at all?

On 21/11/19 12:15 am, Martin Stransky wrote: On 11/20/19 12:12 PM, Scott Anderson wrote: On 21/11/19 12:03 am, Martin Stransky wrote: Hi guys, what happens and is it a correct behavior when application does not use wl_frame_callback at all and just do the drawing (wl_surface_commit

Re: Do I need wl_frame_callback at all?

On 21/11/19 12:03 am, Martin Stransky wrote: Hi guys, what happens and is it a correct behavior when application does not use wl_frame_callback at all and just do the drawing (wl_surface_commit) whatever it has a data do draw? I know it may be sub-optimal to draw more frequently but I'd

Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

On 15/11/19 4:04 am, Drew DeVault wrote: On Fri Nov 15, 2019 at 12:39 AM, Scott Anderson wrote: A hint is merely a hint. The compositor can abide or not by that. This flag will explicitly close the client connection if the buffer can't be scanned out when this flag is passed. This flag

Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

Has any thought been into how this would need to interact with dmabuf-hints[1]? Without that, it seems like it would be a total crapshoot for clients to try and use this flag, since they have no idea what formats+modifers the display controller supports, and instead only has the list that the GPU

Re: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

On 14/11/19 3:08 am, Marius Vlad wrote: Flag used to tell the compositor that it should avoid touching the dmabuf buffer and forward it directly to the display controller. Most likely this flag can be used together with the content-protection protocol. It assures the client that the compositor

Re: wl_subsurace position - double buffered state?

On 30/10/19 10:41 am, Martin Stransky wrote: Hi Guys, while solving a FF bug [1] I'm unable to figure out why a subsurface has wrong offset. There's the related part of wayland-debug log: [1622539.791]  -> wl_compositor@53.create_surface(new id wl_surface@61) [1622539.821]  ->

XDC allocator workshop and Wayland dmabuf hints

(Sorry to CCs for spam, I made an error in my first posting) Hi, There were certainly some interesting changes discussed at the allocator workshop during XDC this year, and I'd like to just summarise my thoughts on it and make sure everybody is on the same page. For those who don't know who I

Re: where is weston-content-protection-client-protocol.h?

On 1/10/19 3:35 pm, Barry Song wrote: Hi Ankit and all, clients/content_protection.c includes weston-content-protection-client-protocol.h, and i found commit 8b40def845c1b965c2888b1f036ef1f19d76 added weston_content_protection_protocol_c and weston_content_protection_client_protocol_h diff

Re: universal planes in drm backend

On 17/09/19 7:38 pm, zou lan wrote: Hi Daniel & all I find the function drm_output_prepare_overlay_view() only use the plane type of WDRM_PLANE_TYPE_OVERLAY. it could be a waste for some planes of type WDRM_PLANE_TYPE_PRIMARY if the universal planes is enable. For example, the kernel define

Re: bo flags isn't passed through wayland-drm protocl, how weston respect these flags?

On 6/08/19 1:03 pm, HalleyZhao wrote: Hi experts: when we create buffer object at wayland client side, there are some usage flags, for example gbm_bo_flags. but when we pass these buffer fd to weston through wayland-drm protocl, these flags are ignored. then, how weston respect these flags

Re: dmabuf modifiers for HW overlays

On 2/08/19 10:19 pm, Martin Stransky wrote: On 8/2/19 12:04 PM, Martin Stransky wrote: Also I wonder if it's feasible to use any modifiers as I need plain/linear buffer to draw into by skia. I suspect when I create the buffer with modifiers and then I map it to CPU memory for SW drawing,

Re: how to implement animation in wayland since window move request is not supported?

On 6/05/19 1:37 pm, Barry Song wrote: sorry for the ascii text picture can't show well in gmail. the animation is pretty much like drop-down terminal - Yakuake https://kde.org/applications/system/yakuake/ when you push a key, the Yakuake will move out from the top. Barry Song

Re: xwayland display variable

On 1/05/19 11:30 pm, Damian Ivanov wrote: Hello, Is it somewhere documented how Xwayland applications are choosing which compositor to display on? e.g 2 compostiors (1 nested or on another VT) wayland-0 and wayland-1 export WAYLAND_DISPLAY=wayland-1 GDK_BACKEND=x11 gedit //starts on wayland-0

Re: [PATCH wayland-protocols] xdg-output: deprecate the xdg_output.done event

This commit makes it so a wl_output.done event is guaranteed to be sent with a xdg_output.done event. Humm, I am not sure I like changing xdg-output to rely on another protocol event, it's looks like a weird mixup to me... As noted below, this is idiomatic in the Wayland protocol. The

Re: wayland-protocols scope and governance

Do we want anything formal regarding the removal of protocols? The one comes to mind currently is xdg-shell-unstable-v5, which most (if not all?) compositors have dropped support for. If something previously widespread falls out of usage and compositors remove their implementations, is there

Re: [PATCH wayland v2] contributing: use Gitlab merge request workflow

be difficult to follow review +comments without using the web interface though, so we do recommend using this +to go through the review process, even if you use other clients to track the +list of available patches. Coding style Reviewed-by: Scott Anderson

Re: Wayland / Weston Multi Display Client-Side Functionality

On 25/02/19 8:21 pm, AMAR SEN wrote: Hi, 1. Is there any client side functionality to handle multiple displays? It can be seen as like a particular client has some options that can direct the server to show frames on either of the displays or both (multiple displays) of them at the same

Re: Question about linux-explicit-synchronization

On 18/02/19 11:02 pm, Daniel Stone wrote: Hi Scott, On Mon, 18 Feb 2019 at 03:27, Scott Anderson wrote: In the Weston implementation, it's simply a case of the compositor getting the fence from the client, using eglWaitSyncKHR (or equivilent) on it, and passing back a release fence from

Question about linux-explicit-synchronization

Hi, I have a question about the usage of zwp_linux_explicit_synchronization_unstable_v1. In the Weston implementation, it's simply a case of the compositor getting the fence from the client, using eglWaitSyncKHR (or equivilent) on it, and passing back a release fence from OUT_FENCE_FD.

Re: [PATCH RFC wayland-protocols v3 1/2] Add secure output protocol

On 2/02/19 1:16 am, Pekka Paalanen wrote: On Mon, 3 Dec 2018 19:14:50 +1300 scott.ander...@collabora.com wrote: From: Scott Anderson This protocol allows a client to ask the compositor to only allow it to be displayed on a "secure" output. This is based on a chromium protocol o

[PATCH wayland] protocol: Add new wl_shm formats

From: Scott Anderson This adds several new wl_shm formats to match the newly added DRM fourcc ones. Signed-off-by: Scott Anderson --- protocol/wayland.xml | 16 1 file changed, 16 insertions(+) diff --git a/protocol/wayland.xml b/protocol/wayland.xml index ea04623..592a53e

[RFC v3 wayland-protocols] inputfd - direct input access protocol

Hi, I thought I would try to push this [1] protocol along, as it's what would be needed for wayland client gamepad input. There is still no client-side "libgamepadinput", so clients are on their own when it comes to handling these devices. Here is a basic proof-of-concept implementation for

[PATCH RFC wayland-protocols v3 1/2] Add secure output protocol

From: Scott Anderson This protocol allows a client to ask the compositor to only allow it to be displayed on a "secure" output. This is based on a chromium protocol of the same name [1]. This protocol is mostly useful for closed systems, where the client can trust the compositor, s

[no subject]

Hi, I've come to realise that it's become a bit of a fool's errand to try and put all of the information related to content security into a single protocol and have the interface be general yet sane, so I've instead redesigned this to be general core which can be extended by other protocols.

[PATCH RFC wayland-protocols v3 2/2] Add HDCP security protocol

From: Scott Anderson This is an extension to the secure output protocol for clients that specifically want to control properties related to HDCP. Signed-off-by: Scott Anderson --- .../secure-output-hdcp-unstable-v1.xml| 120 ++ 1 file changed, 120 insertions(+) create

[PATCH RFC wayland-protocols] Add secure output protocol

From: Scott Anderson This protocol allows a client to ask the compositor to only allow it to be displayed on a "secure" output (e.g. HDCP). This is based on a chromium protocol of the same name [1]. This protocol is mostly useful for closed systems, where the client can trust the

Re: [PATCH RFC wayland-protocols] Add secure output protocol

Hi, As far as I understand, the different types and versions of protection a client would want is based on the resolution of the content, rather than anything about what the content actually is. Is there any particular reason a client would care if their content is being used on a higher

[PATCH RFC wayland-protocols] Add secure output protocol

From: Scott Anderson This protocol allows a client to ask the compositor to only allow it to be displayed on a "secure" output (e.g. HDCP). This is based on a chromium protocol of the same name [1]. This protocol is mostly useful for closed systems, where the client can trust the

Re: [PATCH wayland-protocols v3] Add alpha-compositing protocol

On 16/11/18 6:05 am, Derek Foreman wrote: This looks nice to me, and I have need of something like this. A couple of comments below. On 11/14/18 7:00 PM, Scott Anderson wrote: This protocol specifies a set of interfaces used to control the alpha compositing and blending of surface contents

[PATCH wayland-protocols v3] Add alpha-compositing protocol

This protocol specifies a set of interfaces used to control the alpha compositing and blending of surface contents, based on the Chromium Wayland protocol of the same name [1]. Signed-off-by: Scott Anderson [1] https://chromium.googlesource.com/chromium/src/+/master/third_party/wayland

[PATCH wayland-protocols v2] Add alpha-compositing protocol

This protocol specifies a set of interfaces used to control the alpha compositing and blending of surface contents. It's based on the Chromium Wayland protocol of the same name ([1]) and an old proposal of this protocol ([2]). Differences from v1 proposal: - Add additional "fromsource" blending