Re: [PATCH 0/5] Improve Present support in Xwayland with per window flips

Hi Roman, On 30/08/17 12:24 AM, Roman Gilg wrote: > > Originating from the bug report > > https://bugs.freedesktop.org/show_bug.cgi?id=99702 > > and my own observations with Xwayland misbehaving when outscanning on overlay > planes, this patch series aims at improving Present support in

Re: [PATCH 3/5] present: Add mode for pixmap flips per window

On 30/08/17 12:24 AM, Roman Gilg wrote: > This patch adds a new mode to the internal flip mode API, that > enables per window flips on capable hardware platforms. > > Pixmap flips are possible for every window with a parent window and > without redirection. This sentence is a bit confusing. In

Re: [PATCH 4/5] xwayland: Use Present's flips per window mode

On 30/08/17 12:24 AM, Roman Gilg wrote: > > There is a small change to the window mode in Present as well, that now > calls flip_executed at the end of processing the flip with the > calculated damage. Xwayland then commits the new buffer. As discussed before, I'd prefer if Xwayland instead only

Re: [PATCH 5/5] xwayland: Pixmap flips of child windows on sub-surfaces

On 30/08/17 12:24 AM, Roman Gilg wrote: > This patch enables Pixmap flips for child windows via Wayland > sub-surfaces. That can't be done so easily for the reasons I've explained before (basically, non-Present requests would need to "see" the subsurface contents as well), so I'm afraid I have to

Re: [PATCH 5/5] xwayland: Pixmap flips of child windows on sub-surfaces

There is a mistake in the patch description since the mentioned small change to the Present extension code wasn't necessary in the end. So I reverted the change, but forgot about the description. On Tue, Aug 29, 2017 at 5:24 PM, Roman Gilg wrote: > This patch enables Pixmap

[PATCH 3/5] present: Add mode for pixmap flips per window

This patch adds a new mode to the internal flip mode API, that enables per window flips on capable hardware platforms. Pixmap flips are possible for every window with a parent window and without redirection. Besides the per window flips the new mode diverges from the old screen flipping by

[PATCH 4/5] xwayland: Use Present's flips per window mode

Enables in Rootless mode with Glamor the usage of the new per window flip mode of Present. With this patch per window flips are possible for windows, that own an xwl_window themselves, i.e. windows, that are manually redirected or child windows, that are region equal to their first manually

[PATCH 5/5] xwayland: Pixmap flips of child windows on sub-surfaces

This patch enables Pixmap flips for child windows via Wayland sub-surfaces. If the Wayland compositor doesn't support sub-surfaces we fall back to flips without sub-surfaces when possible as before. A small change to Present is necessary, to restore the window pixmap correctly after an unflip

[PATCH 2/5] present: Put vblank and execute code in separate files

The vblank and execute functions aren't static anymore. Therefore we can put them into separate files in order to increase clarity. Signed-off-by: Roman Gilg --- present/Makefile.am | 4 +- present/meson.build | 2 + present/present.c | 264

[PATCH 1/5] present: Introduce internal flip mode API

The current mode of operation only allows flips per screen. In order to allow other more advanced modes (such as flips per window), introduce an internal API for adding and maintaining those modes easily. A mode "mde" is selected by calling the approriate present_mdemode_init function on a

[PATCH 0/5] Improve Present support in Xwayland with per window flips

Originating from the bug report https://bugs.freedesktop.org/show_bug.cgi?id=99702 and my own observations with Xwayland misbehaving when outscanning on overlay planes, this patch series aims at improving Present support in Xwayland. For that it introduces an internal flip mode API to

Re: Integration of libpointing with Xorg

On Mon, Aug 28, 2017 at 09:32:47PM -0600, Tim Stowell wrote: > Thanks for the information Peter, this is really helpful. > > I can understand how it would be simpler to just use the magic numbers in > libinput's code. I was only wanting to use libpointing because it's the > only implementation of