[PATCH xserver] Xi: don't deliver emulated motion events for non-emulating touches

The touchpoint knows whether it should be emulating or not and we have a check for that later. Check for this before we generate the event and try to deliver it, lest we trigger a bug warning. https://bugzilla.redhat.com/show_bug.cgi?id=1282252 Signed-off-by: Peter Hutterer

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

On 09.03.2016 05:57, Keith Packard wrote: > Michel Dänzer writes: > >> It seems to work fine in my quick testing. However, I'm not sure it's >> worth it, given that v2 of patch 1 fixes holding on to the last HW >> cursor indefinitely, and given the churn it would cause for

Re: [PATCH xserver 1/3] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor (v2)

Michel Dänzer writes: > From: Michel Dänzer > > This reduces code duplication. > > v2: No functional change this time. > Signed-off-by: Michel Dänzer Reviewed-by: Keith Packard -- -keith signature.asc

Re: [PATCH xserver 2/3] xfree86/modes: Check for CRTC transforms in xf86_use_hw_cursor(_argb) (v2)

Michel Dänzer writes: > From: Michel Dänzer > > We currently don't handle transforms for the HW cursor image, so return > FALSE to signal a software cursor must be used if a transform is in use > on any CRTC. > > v2: Check crtc->transformPresent

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

On 09.03.2016 12:46, Keith Packard wrote: > Michel Dänzer writes: > >> Unfortunately, the reality is that at least the radeon and amdgpu >> drivers do use it. > > Even modesetting uses it; there isn't any other public interface to get > the current cursor. > > What do you

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

Michel Dänzer writes: > Unfortunately, the reality is that at least the radeon and amdgpu > drivers do use it. Even modesetting uses it; there isn't any other public interface to get the current cursor. What do you think about eliminating the RefCursor/FreeCursor bits and

[PATCH xserver] xwayland: Make it possible to force CLOCK_MONOTONIC

By default the X server will try CLOCK_MONOTONIC_COARSE before CLOCK_MONOTONIC. This causes various issues for Wayland display servers who may get their internal timestamps from the CLOCK_MONOTONIC, since it may very well happen that a timestamp from CLOCK_MONOTONIC retrieved before a sending an X

Re: [PATCH xserver 1/9] xvmc: Fix unchecked AddResource

On Tue, Mar 8, 2016 at 09:12:34 +0100, walter harms wrote: > > > Am 07.03.2016 23:20, schrieb Julien Cristau: > > Signed-off-by: Julien Cristau > > --- > > Xext/xvmc.c | 17 ++--- > > 1 file changed, 14 insertions(+), 3 deletions(-) > > > > diff --git

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, On 8 March 2016 at 12:07, Pekka Paalanen wrote: > If one justification for server-side repeat is that if the compositor > is hosed and the user cannot see how many characters have been > repeated, then you could as well solve that in the client too, by > throttling your

Re: [PATCH xserver 2/2] xwayland: add a server sync before repeating keys

[oops, forgot to cc the list as well in my reply] On 8 March 2016 at 13:06, Olivier Fourdan wrote: > Hi > > On 8 March 2016 at 12:59, Daniel Stone wrote: > >> Hi, >> >> On 7 March 2016 at 17:45, Olivier Fourdan wrote: >> > Key

[PATCH xserver] xwayland: Correctly detect whether posix_fallocate exists

We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever defined anywhere. This commit makes it so that this macro is defined if the posix_fallocate is detected during configure. Signed-off-by: Jonas Ådahl --- configure.ac | 3 ++-

Re: [PATCH xserver 2/2] xwayland: add a server sync before repeating keys

Hi, On 8 March 2016 at 12:08, Olivier Fourdan wrote: > On 8 March 2016 at 13:06, Olivier Fourdan wrote: >> On 8 March 2016 at 12:59, Daniel Stone wrote: >>> On 7 March 2016 at 17:45, Olivier Fourdan wrote: >>> >

Re: [PATCH xserver 2/2] xwayland: Correctly detect whether posix_fallocate exists

On Tue, Mar 8, 2016 at 18:32:27 +0800, Jonas Ådahl wrote: > On Tue, Feb 23, 2016 at 08:54:47AM +0800, Jonas Ådahl wrote: > > On Fri, Feb 19, 2016 at 11:53:46AM +0100, Julien Cristau wrote: > > > On Fri, Feb 19, 2016 at 15:08:13 +0800, Jonas Ådahl wrote: > > > > > > > We had HAVE_POSIX_FALLOCATE

Re: [PATCH xserver 2/2] xwayland: add a server sync before repeating keys

Hi, On 7 March 2016 at 17:45, Olivier Fourdan wrote: > Key repeat is handled by the X server, but input events need to be > processed and forwarded by the Wayland compositor first. > > Make sure the Wayland compositor is actually processing events, to > avoid repeating keys

Re: [PATCH xserver 2/2] xwayland: Correctly detect whether posix_fallocate exists

On Tue, Feb 23, 2016 at 08:54:47AM +0800, Jonas Ådahl wrote: > On Fri, Feb 19, 2016 at 11:53:46AM +0100, Julien Cristau wrote: > > On Fri, Feb 19, 2016 at 15:08:13 +0800, Jonas Ådahl wrote: > > > > > We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever > > > defined anywhere. This

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

On Tue, 8 Mar 2016 11:08:45 +0100 Hans de Goede wrote: > Hi, > > On 08-03-16 10:15, Pekka Paalanen wrote: > > On Mon, 7 Mar 2016 19:25:54 +0100 > > Hans de Goede wrote: > > > >> Hi, > >> > >> On 07-03-16 19:23, Hans de Goede wrote: > >>> Hi, > >>>

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, On 8 March 2016 at 09:15, Pekka Paalanen wrote: > On Mon, 7 Mar 2016 19:25:54 +0100 > Hans de Goede wrote: >> On 07-03-16 19:23, Hans de Goede wrote: >> > On 07-03-16 18:44, Olivier Fourdan wrote: >> > Why not simply rely on the keyrepeat of the

[PATCH xserver 1/3] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor (v2)

From: Michel Dänzer This reduces code duplication. v2: No functional change this time. Signed-off-by: Michel Dänzer --- hw/xfree86/modes/xf86Cursors.c | 10 ++ 1 file changed, 2 insertions(+), 8 deletions(-) diff --git

[PATCH xserver 2/3] xfree86/modes: Check for CRTC transforms in xf86_use_hw_cursor(_argb) (v2)

From: Michel Dänzer We currently don't handle transforms for the HW cursor image, so return FALSE to signal a software cursor must be used if a transform is in use on any CRTC. v2: Check crtc->transformPresent instead of crtc->transform_in_use. The latter is TRUE for

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, On 08-03-16 10:15, Pekka Paalanen wrote: On Mon, 7 Mar 2016 19:25:54 +0100 Hans de Goede wrote: Hi, On 07-03-16 19:23, Hans de Goede wrote: Hi, On 07-03-16 18:44, Olivier Fourdan wrote: Key repeat is handled by the X server, but for Wayland, the key press/release

Re: [PATCH v4 02/13] modesetting: scanout_pixmap_gpu one call only

On 04.03.2016 11:47, Alex Goins wrote: > Subsequent commits will involve multiple calls to > rrCrtcSetScanoutPixmap(ppix) without a call to rrCrtcSetScanoutPixmap(NULL) > in between. This causes drmmode_set_scanout_pixmap_gpu() to track damage > multiple times but ultimately only stop tracking on

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

On 25.12.2015 03:06, Keith Packard wrote: > Michel Dänzer writes: > >> From: Michel Dänzer >> >> This reduces code duplication. >> >> One side effect of this change is that xf86_config->cursor will no longer >> be updated for cursors which cannot use

Re: [PATCH xserver 1/9] xvmc: Fix unchecked AddResource

Am 07.03.2016 23:20, schrieb Julien Cristau: > Signed-off-by: Julien Cristau > --- > Xext/xvmc.c | 17 ++--- > 1 file changed, 14 insertions(+), 3 deletions(-) > > diff --git a/Xext/xvmc.c b/Xext/xvmc.c > index 64eda92..7565c17 100644 > --- a/Xext/xvmc.c > +++

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

On Mon, 7 Mar 2016 19:25:54 +0100 Hans de Goede wrote: > Hi, > > On 07-03-16 19:23, Hans de Goede wrote: > > Hi, > > > > On 07-03-16 18:44, Olivier Fourdan wrote: > >> Key repeat is handled by the X server, but for Wayland, the key > >> press/release events need to be

Re: [PATCH xserver] xwayland: Correctly detect whether posix_fallocate exists

On Tue, Mar 8, 2016 at 20:05:33 +0800, Jonas Ådahl wrote: > We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever > defined anywhere. This commit makes it so that this macro is defined if > the posix_fallocate is detected during configure. > > Signed-off-by: Jonas Ådahl

Re: [PATCH xserver v3] xwayland: add glamor Xv adaptor

Hi Adam, I had posted a revisited version using GL_MAX_TEXTURE_SIZE to determine the encoder size as per your review last week, is there anything else that needs rework? Cheers, Olivier - Original Message - > This adds an Xv adaptor using glamor. > > Signed-off-by: Olivier Fourdan

Re: [PATCH xserver] xwayland: Correctly detect whether posix_fallocate exists

On Tue, 2016-03-08 at 14:15 +0100, Julien Cristau wrote: > On Tue, Mar  8, 2016 at 20:05:33 +0800, Jonas Ådahl wrote: > > > We had HAVE_POSIX_FALLOCATE checks, but no such macros were ever > > defined anywhere. This commit makes it so that this macro is defined if > > the posix_fallocate is

Re: [PATCH xserver 0/9] double frees in AddResource failure paths

On Tue, 2016-03-08 at 00:30 +0100, Rémi Cardona wrote: > Le 07/03/2016 23:20, Julien Cristau a écrit : > > Hi, > > > > prompted by Adam's recent fixes for unchecked AddResource, I've been > > looking at the failure paths, and found a number of places where it > > looks like we're freeing things

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, On Tue, Mar 8, 2016 at 7:09 AM, Daniel Stone wrote: >> If one justification for server-side repeat is that if the compositor >> is hosed and the user cannot see how many characters have been >> repeated, then you could as well solve that in the client too, by >>

[PATCH xserver 2/2 v2] xwayland: add a server sync before repeating keys

Key repeat is handled by the X server, but input events need to be processed and forwarded by the Wayland compositor first. Make sure the Wayland compositor is actually processing events, to avoid repeating keys in xwayland while the Wayland compositor cannot deal with input events for whatever

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi, > This still suffers from your priority-starvation-bug. If a simple > ping/pong protocol barrier doesn't solve the issue, why would the > timer? You'd have to put the timer on lowest priority to make that > work, but then again you can do the same for wl_display_sync. Yup, indeed, you're

Re: [PATCH xserver 0/2] RFC: Sync key repeat with Wayland compositor

Hi On Tue, Mar 8, 2016 at 4:41 PM, Ray Strode wrote: > On Tue, Mar 8, 2016 at 7:09 AM, Daniel Stone wrote: >>> If one justification for server-side repeat is that if the compositor >>> is hosed and the user cannot see how many characters have been >>>

Re: [PATCH] modesetting: add support for background none.

As mentioned in the original email, it relies on this series: https://lists.x.org/archives/xorg-devel/2016-February/048758.html On Tue, Mar 8, 2016 at 9:41 AM, Adam Jackson wrote: > On Wed, 2016-02-10 at 15:45 +1000, Dave Airlie wrote: > >> From: Dave Airlie

Re: [PATCH xserver] build: Enable vidmode independently from Xorg

On Fri, 2016-03-04 at 16:24 +0100, Rui Matos wrote: > This allows building Xwayland without Xorg and still include the > vidmode extension. > > v2: Use PKG_CHECK_EXISTS instead of PKG_CHECK_MODULES remote: I: patch #75875 updated using rev 40a164b8f4e720b0d6ebf228ee175eb397ffeec2. remote: I: 1

Re: [PATCH] modesetting: add support for background none.

On Wed, 2016-02-10 at 15:45 +1000, Dave Airlie wrote: > From: Dave Airlie > > This adds support using glamor for background None. > > loosely based off the amdgpu code. relies on the > glamor_finish code. > > Signed-off-by: Dave Airlie NAK: > +void >

Re: [PATCH] glamor: Fix XvPutImage when src_y != 0

On Wed, 2016-02-10 at 16:40 +0100, Hans de Goede wrote: > We already take src_y into account when uploading the src data by > starting at the top line of the src data when uploading. > > Adjust src_y accordingly when rendering. > > Signed-off-by: Hans de Goede remote: I:

Re: [PATCH xserver 1/5] xfree86/modes: Refactor xf86_use_hw_cursor_argb to use xf86_use_hw_cursor

Michel Dänzer writes: > It seems to work fine in my quick testing. However, I'm not sure it's > worth it, given that v2 of patch 1 fixes holding on to the last HW > cursor indefinitely, and given the churn it would cause for external > drivers. I guess I don't see how this

Re: [PATCH xserver 2/2] glamor: Source pictures are always depth 32

On Tue, 2016-02-23 at 17:19 +0900, Michel Dänzer wrote: > From: Michel Dänzer > > We were using the destination pixmap depth to determine the source > picture format. > > Fixes incorrect text rendering with some MATE desktop GTK3 themes. > > Bugzilla:

Re: [PATCH v4 02/13] modesetting: scanout_pixmap_gpu one call only

> AFAICT RRReplaceScanoutPixmap may call set_scanout_pixmap while > randr_crtc->scanout_pixmap is already non-NULL (and pointing to a > different pixmap). That seems to be true now that you mention it. I haven't paid that much attention to RRReplaceScanoutPixmap(), since it doesn't seem to get

[PULL] Reviewed cursor changes

Hi Keith / Adam, the following changes since commit a3e681eafa5355b8bb3b099d47983f14f0d5e197: glamor: Source pictures are always depth 32 (2016-03-08 15:17:19 -0500) are available in the git repository at: git://people.freedesktop.org/~daenzer/xserver for-master for you to fetch changes