Re: wayland-protocols scope and governance

On Wed, Nov 13, 2019 at 16:21, Jonas Ådahl wrote: On Tue, Nov 12, 2019 at 08:13:58PM +, Daniel Stone wrote: Hi, On Thu, 10 Oct 2019 at 16:12, Simon Ser > wrote: > This document governs the maintenance of wayland-protocols and serves to outline > the

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: [PATCH] unstable/linux-dmabuf: Add 'direct_display' flag

Can you elaborate more on non-DRM use-cases? Most compositors are already going to use direct scan-out as much as possible, and can make reasonably well informed choices about when to do so. For example, fullscreen surfaces will generally always be scanned out if possible. More interesting

Re: wayland-protocols scope and governance

On Tue, Nov 12, 2019 at 08:13:58PM +, Daniel Stone wrote: > Hi, > > On Thu, 10 Oct 2019 at 16:12, Simon Ser wrote: > > This document governs the maintenance of wayland-protocols and serves to > > outline > > the broader process for standardization of protocol extensions in the > > Wayland

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

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 will never handle the buffer over to the

Re: Getting a compositor display name?

On Wed, Nov 13, 2019 at 11:00:05AM +, Simon Ser wrote: > On Wednesday, November 13, 2019 11:11 AM, Pekka Paalanen > wrote: > > > However, my fear with adding such information is that then clients > > might start adding conditional code paths based on the Wayland > > compositor name or

Re: Getting a compositor display name?

On Wednesday, November 13, 2019 12:25 AM, Drew DeVault wrote: > I don't know of a way to do this today, but I think it would make for a > reasonable addition to wl_display. Additions cannot be made to wl_display, because it's not versioned. Only globals retrieved through wl_registry.bind and

Re: Getting a compositor display name?

On Wednesday, November 13, 2019 11:11 AM, Pekka Paalanen wrote: > However, my fear with adding such information is that then clients > might start adding conditional code paths based on the Wayland > compositor name or version, which is an incorrect approach. Client > behaviour that depends on

Re: Getting a compositor display name?

On Tue, 12 Nov 2019 12:59:40 -0700 "Ronan Pigott" wrote: > Hello, > > So EWMH has this thing "_NET_SUPPORTING_WM_CHECK": > > https://specifications.freedesktop.org/wm-spec/wm-spec-1.3.html#idm140130317670464 > > where the WM maintains a special window with some atoms for > introspecting the

Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user

Hi Carlos, On Fri, Oct 18, 2019 at 01:08:36AM +0200, Carlos Garnacho wrote: > Hi Pekka, > > Thank you for your comments! > > On Wed, Oct 16, 2019 at 11:31 AM Pekka Paalanen wrote: > > > On Wed, 16 Oct 2019 10:54:08 +0200 > > Olivier Fourdan wrote: > > > > > Hey Carlos, > > > > > > On Wed, Oct