Re: [PATCH 3/5] scanner: introduce --object-type option

On Wed, Jan 24, 2018 at 07:15:09PM +, Emil Velikov wrote: > On 24 January 2018 at 18:20, Derek Foreman wrote: > > On 2018-01-22 09:30 AM, Emil Velikov wrote: > >> > >> On 22 August 2017 at 14:02, Emil Velikov wrote: > >>> > >>> On 18 August

[PATCH weston] xwm: Fix icon surface ownership

The cairo surface used for the icon must be completely given to the frame as soon as said frame has been created. To prevent both the window and the frame from sharing ownership of the icon, we set window->icon_surface back to NULL right after creating or changing the frame, only keeping it there

Re: [PATCH weston] RFC: libweston/compositor-drm: Add support for drm-lease.

Hi Marius, The protocol changes I suggested would require a fair bit of work here, but I've enclosed a few comments on the implementation. Also, do you have a client you're using for this somewhere, that we could use to test? On 24 January 2018 at 19:11, Marius Vlad

Re: [PATCH wayland-protocols] RFC: unstable: DRM lease support

Hi Marius, Thanks a lot for taking this on! It would be great to get this merged. On 24 January 2018 at 19:09, Marius Vlad wrote: > + > + > + This interface makes use of DRM lease written by Keith Packard. > + It requires libdrm at least 2.4.89 and a

Re: [PATCH weston v4] xwm: Add icon support to the frame

On 2017-12-01 02:47 PM, Quentin Glidic wrote: On 12/1/17 7:20 PM, Emmanuel Gil Peyrot wrote: This fetches the _NET_WM_ICON property of the X11 window, and use the first image found as the frame icon. This has been tested with various X11 programs, and improves usability and user-friendliness a

Re: [PATCH 3/5] scanner: introduce --object-type option

On 24 January 2018 at 18:20, Derek Foreman wrote: > On 2018-01-22 09:30 AM, Emil Velikov wrote: >> >> On 22 August 2017 at 14:02, Emil Velikov wrote: >>> >>> On 18 August 2017 at 13:05, Pekka Paalanen wrote: >>> >>

[PATCH weston] RFC: libweston/compositor-drm: Add support for drm-lease.

DRM leases is a method developed by Keith Packard to allow other application manage the output of a display/VR, while a DRM master is already owning the outputs resources. A more thorough explanation and terminology can be found at [1]. This patch adds support for DRM lease. libdrm is lease-aware

[PATCH wayland-protocols] RFC: unstable: DRM lease support

Simple protocol extension for DRM leases, based on the work done by Keith Packard in libdrm [1] and in the Linux kernel [2]. There are two requests (create/revoke) and three events (created/revoked/failed). The server is responsible for choosing which output to lease. Another patch will follow

Re: [PATCH xserver] xwayland: Support for BTN_STYLUS3 kernel events

On Thu, Nov 9, 2017 at 2:19 PM, Jason Gerecke wrote: > On Tue, Nov 7, 2017 at 2:37 PM, Peter Hutterer > wrote: >> On Tue, Nov 07, 2017 at 11:09:44AM -0800, Jason Gerecke wrote: >>> BTN_STYLUS3 has been introduced by the Linux 4.15 kernel to report

Re: [PATCH 3/5] scanner: introduce --object-type option

On 2018-01-22 09:30 AM, Emil Velikov wrote: On 22 August 2017 at 14:02, Emil Velikov wrote: On 18 August 2017 at 13:05, Pekka Paalanen wrote: The exported configuration would then be: LOCAL_INTERFACE_DECL=extern EXTERN_INTERFACE_DECL=extern

Re: [PATCH xserver] xwayland: avoid a crash with empty window pixmaps

Hi, On 24 January 2018 at 16:17, Adam Jackson wrote: > On Wed, 2018-01-24 at 11:36 +0100, Olivier Fourdan wrote: >> So basically, just remove the “if >> (RegionNotEmpty(DamageRegion(xwl_window->damage)))” would suffice? > > Worth a try anyway. I'm still just guessing at the root

[PATCH xserver] xwayland: remove dirty window unconditionally on unrealize

This is a rare occurrence of a crash in Xwayland for which I don't have the reproducing steps, just a core file. The backtrace looks as follow: #0 raise () from /usr/lib64/libc.so.6 #1 abort () from /usr/lib64/libc.so.6 #2 OsAbort () at utils.c:1361 #3 AbortServer () at log.c:877

Re: [PATCH v3 xserver 1/2] xwayland: Add optional xdg-output support

On Wed, 2018-01-24 at 11:31 +0100, Olivier Fourdan wrote: > Small bump, would need to land this patch for 1.20 so we can continue > with fixing mutter once this is available in an Xwayland release :) Thanks for the poke. This didn't quite build with meson, needed to generate the new client

Re: [PATCH xserver] xwayland: avoid a crash with empty window pixmaps

On Wed, Jan 24, 2018 at 5:17 PM, Adam Jackson wrote: > On Wed, 2018-01-24 at 11:36 +0100, Olivier Fourdan wrote: > > > So basically, just remove the “if > > (RegionNotEmpty(DamageRegion(xwl_window->damage)))” would suffice? > > Worth a try anyway. I'm still just guessing at the

Re: [PATCH xserver] xwayland: avoid a crash with empty window pixmaps

On Wed, 2018-01-24 at 11:36 +0100, Olivier Fourdan wrote: > So basically, just remove the “if > (RegionNotEmpty(DamageRegion(xwl_window->damage)))” would suffice? Worth a try anyway. I'm still just guessing at the root cause. - ajax ___ wayland-devel

[PATCH wayland] doc: Document behavior of non-nullable object arguments in clients

--- src/wayland-util.h | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/src/wayland-util.h b/src/wayland-util.h index caeac82..b6cbe0e 100644 --- a/src/wayland-util.h +++ b/src/wayland-util.h @@ -78,12 +78,23 @@ extern "C" { * wl_message is to a protocol

Re: [PATCH v14 23/41] compositor-drm: Use plane_coords_for_view for cursor

On Wed, 20 Dec 2017 12:26:40 + Daniel Stone wrote: > Use the new helper to populate the cursor state as well, with some > special-case handling to account for how we always upload a full-size > BO. > > Signed-off-by: Daniel Stone > Reported-by:

Re: [PATCH v14 22/41] compositor-drm: Use plane_state_coords_for_view for scanout

On Wed, 20 Dec 2017 12:26:39 + Daniel Stone wrote: > Use the shiny new helper we have for working through scanout as well. > > Signed-off-by: Daniel Stone > --- > libweston/compositor-drm.c | 81 >

Re: [PATCH xserver] xwayland: avoid a crash with empty window pixmaps

Hi Adam, On Tue, Jan 23, 2018 at 6:41 PM, Adam Jackson wrote: > > Map / draw / unmap without hitting BlockHandler? I think > xwl_unrealize_window() might be broken for that case: > > /* ... */ > wl_surface_destroy(xwl_window->surface); > if

Re: [PATCH v3 xserver 1/2] xwayland: Add optional xdg-output support

Hi, On Mon, Dec 18, 2017 at 8:52 AM, Olivier Fourdan wrote: > Hi, > > xdg-support has now been added to mutter (in git master), can we consider > this patch (only this one for now) which adds xdg-output support to > Xwayland? > > Because of the difference between

Re: [PATCH v14 21/41] [XXX] compositor-drm: Only disallow scaling for overlay planes

On Wed, 20 Dec 2017 12:26:38 + Daniel Stone wrote: > Now we have a more comprehensive overview of the transform we're going > to apply, use this to explicitly disallow scaling and rotation. > > XXX: This does not actually disallow rotation for square surfaces. >

Re: libinput touchscreen maxTouchPoints

On Wed, Jan 24, 2018 at 10:18 AM, Peter Hutterer wrote: > On Wed, Jan 24, 2018 at 10:04:52AM +0100, Johannes Pointner wrote: >> Hello, >> >> I have noticed that since we are using xf86-input-libinput all our >> touchscreens (resistive and pcap) reporting a value of 15

Re: libinput touchscreen maxTouchPoints

On Wed, Jan 24, 2018 at 10:04:52AM +0100, Johannes Pointner wrote: > Hello, > > I have noticed that since we are using xf86-input-libinput all our > touchscreens (resistive and pcap) reporting a value of 15 for > maxTouchPoints. > After further looking into this I saw that xf86-input-libinput

libinput touchscreen maxTouchPoints

Hello, I have noticed that since we are using xf86-input-libinput all our touchscreens (resistive and pcap) reporting a value of 15 for maxTouchPoints. After further looking into this I saw that xf86-input-libinput sets this value fix to 15. I also checked if it is possible to get this info from

Re: [PATCH v14 20/41] compositor-drm: Fully account for buffer transformation

On Wed, 20 Dec 2017 12:26:37 + Daniel Stone wrote: > In our new and improved helper to determine the src/dest values for a > buffer on a given plane, make sure we account for all buffer > transformations, including viewport clipping. > > Rather than badly open-coding