[PATCH xserver v3] xwayland: Bind pointer constraints global

Will be used by the pointer warp emulator. Signed-off-by: Jonas Ådahl Reviewed-by: Peter Hutterer --- Changes since v2: Fix git history rewrite fail (return type of previous patch added in this one). hw/xwayland/.gitignore | 2 ++

[PATCH xserver v3] xwayland: Bind the relative pointer manager

Will be used for getting unaccelerated motion events and later for relative motions used by a pointer warp emulator. Signed-off-by: Jonas Ådahl Reviewed-by: Peter Hutterer --- Changes since v2: Fixed git history rewrite error (function return type

Re: [PATCH xserver 10/14 v2] xwayland: Set unaccelerated pointer motion delta if available

On Wed, 2016-09-28 at 16:57 -0400, Adam Jackson wrote: > On Tue, 2016-09-13 at 15:17 +0800, Jonas Ådahl wrote: > > > +dx_unaccel = xwl_seat->pending_pointer_event.dx_unaccel; > > +dy_unaccel = xwl_seat->pending_pointer_event.dy_unaccel; > > +

Re: [PATCH xserver 0/4] render cleanups

Eric Anholt writes: > I started working on using sampler objects as a step toward doing > sampler views, and found I wanted to delete a bunch of code first. > > Eric Anholt (4): > glamor: Require GL_OES_texture_border_clamp for GLES2. > glamor: Remove many unused glamor

Re: [PATCH xserver 10/14 v2] xwayland: Set unaccelerated pointer motion delta if available

On Tue, 2016-09-13 at 15:17 +0800, Jonas Ådahl wrote: > +dx_unaccel = xwl_seat->pending_pointer_event.dx_unaccel; > +dy_unaccel = xwl_seat->pending_pointer_event.dy_unaccel; > +valuator_mask_set_absolute_unaccelerated(, 0, x, > dx_unaccel); > +

[PATCH xserver 2/4] glamor: Remove many unused glamor util functions.

Signed-off-by: Eric Anholt --- glamor/glamor_utils.h | 171 -- 1 file changed, 171 deletions(-) diff --git a/glamor/glamor_utils.h b/glamor/glamor_utils.h index 561761167fd8..e6398692e3d6 100644 --- a/glamor/glamor_utils.h +++

[PATCH xserver 0/4] render cleanups

I started working on using sampler objects as a step toward doing sampler views, and found I wanted to delete a bunch of code first. Eric Anholt (4): glamor: Require GL_OES_texture_border_clamp for GLES2. glamor: Remove many unused glamor util functions. glamor: Remove #if 0-ed picture

[PATCH xserver 3/4] glamor: Remove #if 0-ed picture dumping code.

I don't think anybody has run this code since it was pulled into the server. Signed-off-by: Eric Anholt --- glamor/glamor_render.c | 5 - glamor/glamor_utils.h | 379 - 2 files changed, 384 deletions(-) diff --git

[PATCH xserver 4/4] glamor: Fix link failure on GLES2.

Current Mesa requires that the precision qualifier on uniforms matches between stages, even if (as in this case) the uniform isn't used in one of the stages. Signed-off-by: Eric Anholt --- glamor/glamor_program.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff

[PATCH xserver 1/4] glamor: Require GL_OES_texture_border_clamp for GLES2.

The extension came out in 2000, and all Mesa-supported hardware that can do glamor supports it. We were already relying on the ARB version being present on desktop. Signed-off-by: Eric Anholt --- glamor/glamor.c| 19 +++ glamor/glamor_render.c | 22

Re: [PATCH xserver 05/14 v2] xwayland: Bind the relative pointer manager

On Tue, 2016-09-13 at 15:16 +0800, Jonas Ådahl wrote: >  } >   >  static void > +init_relative_pointer_manager(struct xwl_screen *xwl_screen, > +  uint32_t id, uint32_t version) > +{ > +xwl_screen->relative_pointer_manager = > +

[PATCH xserver] Fix id in error when resource does not exist

Always set client->errorValue before returning an error. Test program: #include #include #include #define BAD_VALUE 0xFACE0FF int main(int argc, char *argv[]) { int screen = 0; xcb_connection_t *c = xcb_connect(NULL, ); if (!c) { printf("Cannot connect\n");

Re: [PATCH xserver] Enable XTRANS_SEND_FDS on FreeBSD, DragonFly and OpenBSD

On Fri, 2016-09-23 at 11:36 +0200, François Tigeot wrote: > This code is based on local patches which had been sitting in > FreeBSD and OpenBSD ports. > > Reviewed-by: Matthieu Herrb > Signed-off-by: François Tigeot remote: I: patch #111872 updated

Re: [PATCH xserver] test: Re-enable a couple of GetImage tests

Adam Jackson writes: > Fixed in 6c6f09aac. Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info:

[PATCH xserver] test: Re-enable a couple of GetImage tests

Fixed in 6c6f09aac. Signed-off-by: Adam Jackson --- test/scripts/xinit-piglit-session.sh | 3 --- 1 file changed, 3 deletions(-) diff --git a/test/scripts/xinit-piglit-session.sh b/test/scripts/xinit-piglit-session.sh index 0f0c794..c26735d 100755 ---

Re: [PATCH xserver] xace: Don't censor window borders

On Sun, 2016-09-25 at 14:19 +0300, Keith Packard wrote: > GetImage is allowed to return window border contents, so don't remove > that from the returned image. > > Signed-off-by: Keith Packard Merged: remote: I: patch #112070 updated using rev

Re: [PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

Adam Jackson writes: > I have a plan to deal with 24bpp, very harshly indeed. You know how much time I spent writing that code. You're deleting some of the "finest" bitblt in the server. > You do appear to be correct though, xfree86 still has paths by which > you can ask for a

Re: [xserver PULL for 1.19 v2] Various modesetting and other fixes

On Tue, 2016-09-27 at 13:00 +0200, Hans de Goede wrote: > And here is the git reqeuest-pull output for the updated > pull-req: > > The following changes since commit ba199cb90157cefab01183f2e2c909895df73321: > >    glamor: Make glamor_sync_init work with --disable-xshmfence (2016-09-25 >

Re: [Pull request]: couple of fixes for xwayland

On Fri, 2016-09-23 at 06:24 -0400, Olivier Fourdan wrote: > The following changes since commit d0c5d205a919fc1d2eb599356090b58b1bf0176d: > >   dix: Make InitCoreDevices() failures more verbose. (2016-09-21 21:11:40 > +1000) > > are available in the git repository at: > >  

Re: [PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

On Wed, 2016-09-28 at 10:19 -0700, Keith Packard wrote: > You'll need to deal with 24bpp separately... I have a plan to deal with 24bpp, very harshly indeed. You do appear to be correct though, xfree86 still has paths by which you can ask for a 24bpp pixmap/wire format, so I can't assume we'll

Re: [PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

Adam Jackson writes: > diff --git a/fb/fbimage.c b/fb/fbimage.c > index 59daa21..8f5f3dc 100644 > --- a/fb/fbimage.c > +++ b/fb/fbimage.c > @@ -250,13 +250,16 @@ fbGetImage(DrawablePtr pDrawable, > > pm = fbReplicatePixel(planeMask, srcBpp); > dstStride =

[PATCH xserver 1/2] fb: Handle ZPixmap planemask in GetImage the other way around

Formerly we'd zero the image data and then pull out a plane at a time. It's faster to apply the planemask after the fact, since that turns the GetImage into a memcpy: 10.0 101000.0 (1.010) (copy 0x) ShmGetImage 10x10 square 42400.0 59400.0 (1.401) (copy 0x) ShmGetImage

[PATCH xserver 2/2] glamor: Avoid software fallback for planemasked ZPixmap GetImage

Same trick as in fb: just do a normal GetImage and deal with the planemask on the CPU if you have to. Since the software fallback hit for glamor is pretty brutal, this is a much more impressive win for glamor than it was for fb: 11100.0 87700.0 (7.901) (copy 0x) ShmGetImage 10x10

Re: [PATCH xserver] glamor: Fall back to software for CopyPlane if we need to

On Wed, 2016-09-28 at 09:52 +0900, Michel Dänzer wrote: > Reviewed-by: Michel Dänzer remote: I: patch #112436 updated using rev fd4a6dc06fcf8671d616af52025e19200c79e404. remote: I: 1 patch(es) updated to state Accepted. To ssh://git.freedesktop.org/git/xorg/xserver

Re: [PATCH xserver v3 11/11] test: Run xts against Xephyr -glamor when present.

On Sun, 2016-09-25 at 13:30 -0700, Eric Anholt wrote: > v2: Drop x8r8g8b8 skip, now that it's fixed. Series merged: remote: Updating patchwork state for https://patchwork.freedesktop.org/project/Xorg/list/ remote: I: patch #111697 updated using rev add49792608171feef8090f7520cfa02d2daae9c.

Re: [PATCH] xwayland: Close the shm fd as early as possible

On 5 February 2016 at 14:25, Pekka Paalanen wrote: > On Fri, 5 Feb 2016 14:44:29 +0100 > Rui Matos wrote: > >> Keeping the shm fd open beyond pixmap creation means we can easily >> reach the open file descriptor limit if an X client asks us to create

Re: [PATCH xserver] modesetting: always set a hardware cursor when requested to load one.

Hello Hans, On 28.09.2016 15:37, Hans de Goede wrote: Hi Michael, On 28-09-16 14:47, Michael Thayer wrote: [...] On 09/16/2016 06:52 PM, Michael Thayer wrote: When the X server asks us to load a hardware cursor, that request is always followed up by a request to show it if we report

[PATCH xserver v2] autobind GPUs to the screen

From: Dave Airlie This is a modified version of a patch we've been carry-ing in Fedora and RHEL for years now. This patch automatically adds secondary GPUs to the master as output sink / offload source making e.g. the use of slave-outputs just work, with requiring the user to

Re: [PATCH xserver] modesetting: always set a hardware cursor when requested to load one.

Hi Michael, On 28-09-16 14:47, Michael Thayer wrote: Hello, On 28.09.2016 09:58, Hans de Goede wrote: Hi, On 28-09-16 05:05, Michel Dänzer wrote: [...] On 09/16/2016 06:52 PM, Michael Thayer wrote: When the X server asks us to load a hardware cursor, that request is always followed up by

Re: [PATCH xserver] modesetting: always set a hardware cursor when requested to load one.

Hello, On 28.09.2016 09:58, Hans de Goede wrote: Hi, On 28-09-16 05:05, Michel Dänzer wrote: [...] On 09/16/2016 06:52 PM, Michael Thayer wrote: When the X server asks us to load a hardware cursor, that request is always followed up by a request to show it if we report success, or to hide

[PATCH xserver v2] xwayland: Apply "last pointer window" check only to the pointer device

The checks in xwayland's XYToWindow handler pretty much assumes that the sprite is managed by the wl_pointer, which is not entirely right, given 1) The Virtual Core Pointer may be controlled from other interfaces, and 2) there may be other SpriteRecs than the VCP's. This makes XYToWindow calls

Re: [PATCH xserver 1/2] xwayland: Apply "last pointer window" check only to the pointer device

Hi :), On Wed, Sep 28, 2016 at 9:25 AM, Olivier Fourdan wrote: > Hey Carlos, > > - Original Message - >> The checks in xwayland's XYToWindow handler pretty much assumes that the >> sprite is managed by the wl_pointer, which is not entirely right, given >> 1) The

Re: [PATCH xserver] modesetting: always set a hardware cursor when requested to load one.

Hi, On 28-09-16 05:05, Michel Dänzer wrote: On 27/09/16 10:54 PM, Michael Thayer wrote: On 27.09.2016 12:06, Hans de Goede wrote: On 23-09-16 10:20, Hans de Goede wrote: On 09/16/2016 06:52 PM, Michael Thayer wrote: When the X server asks us to load a hardware cursor, that request is always

Re: [PATCH xserver 1/2] xwayland: Apply "last pointer window" check only to the pointer device

Hey Carlos, - Original Message - > The checks in xwayland's XYToWindow handler pretty much assumes that the > sprite is managed by the wl_pointer, which is not entirely right, given > 1) The Virtual Core Pointer may be controlled from other interfaces, and > 2) there may be other

Re: [PATCH xserver] modesetting: always set a hardware cursor when requested to load one.

On Wed, Sep 28, 2016 at 12:05 PM, Michel Dänzer wrote: > On 27/09/16 10:54 PM, Michael Thayer wrote: >> On 27.09.2016 12:06, Hans de Goede wrote: >>> On 23-09-16 10:20, Hans de Goede wrote: On 09/16/2016 06:52 PM, Michael Thayer wrote: > When the X server asks us to