[PATCH xserver] xwayland: add envvar XWAYLAND_NO_GLAMOR

XWAYLAND_NO_GLAMOR t odiable glamor support in Xwayland. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-glamor.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c index b3d0aab..45de54f

[PATCH xserver] xwayland: do not set checkRepeat on master kbd

the joystick buttons. Adding the checkRepeat handler on the VCK is useless anyway, so remove it and avoid the crash in keyboard_check_repeat() when trying to get the Xwayland seat. Bugzilla: https://bugzilla.redhat.com/1416244 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> ---

[PATCH xserver] xwayland: Make sure we have a focus window

_frame() and relative_pointer_handle_relative_motion() prior to calling dispatch_pointer_motion_event() like it's done in pointer_handle_motion(). Bugzilla: https://bugzilla.redhat.com/1410804 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 6 ++

Re: [PATCH xserver] xwayland: Do not assume we have a seat

Hi Peter, > what device is this called for? quick skim of the xwayland sources indicates > that a device is only created if we have a seat, so I wonder if the repeat is > called for the wrong device here? The keyboard_check_repeat() handler is called directly from AccessXRepeatKeyExpire() [1].

[PATCH xserver] xwayland: Do not assume we have a seat

t checking if the xwl_seat is non-NULL. Bugzilla: https://bugzilla.redhat.com/1416244 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 8 +++- 1 file changed, 7 insertions(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/

Re: xserver 1.19.2 call for patches

Hi, > I'd like to do another 1.19 soonish, say middle of next week. If you've > got favorite patches you'd like to see included, please write their > sha1s on the back of a $50 bill and send them to me. > > Alternatively, reply to this email, or send a pull request. FWIW I reckon we should

Re: [PATCH v2 xserver] os: log a bug whenever WriteToClient is called from the input thread

> The input thread should generate events, not send them. Make it easier to > find the instances where it's doing so. > > Signed-off-by: Peter Hutterer <peter.hutte...@who-t.net> > Tested-by: Olivier Fourdan <ofour...@redhat.com> > --- > Changes to v1: > - ad

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

Hi, > > +extern inline int > > +in_input_thread(void); > > + > > maybe i am old fashion but this should be done with input.h, should it ? No, I don't think this is possible (in the middle of a stable release) nor even suitable, it's not a new API intended for drivers to use, it's purely

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

WriteToClient(ClientPtr who, int count, const void > > *__buf) > > int padBytes; > > const char *buf = __buf; > > > > +BUG_RETURN_VAL_MSG(in_input_thread(), 0, > > + " %s called from input thread *\n&

[PATCH xserver] configure: Xephyr, xfake and xfbdev require kdrive

Raise an error at configure time if one of the DDX that require kdrive is enabled but kdrive itself is not. That avoids the build to silently ignore Xephyr, Xfake and Xfbdev if --enable-kdrive is not set as well. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- configure.a

Re: [RFC xserver] os: log a bug whenever WriteToClient is called from the input thread

Bool multicount = FALSE; > #endif > -- > 2.9.3 It works a treat, brilliant - Within not even a second approaching the stylus to the tablet, Xorg was logging messages about calling WriteToClient() from the input thread, it's just awesome! Tested-by: Olivier Fourdan <ofo

Re: [PATCH RFC xserver] os: Add a mutex to protect io buffers

Hi Alan, > >>> WriteToClient() can be called from XIChangeDeviceProperty() so from the > >>> InputThread which is a problem as it allocates and free the input and > >>> output buffers. > > > > That seems like a bug to me; the input thread isn't supposed to be > > directly interacting with

Re: [PATCH RFC xserver] os: Add a mutex to protect io buffers

Hi Peter, > > > --- > > >  RFC: This is probably sub-optimal and broken in many places, but it > > >   seems to avoid the memory corruption (so far)... At least it's a > > >   start, I guess. > > > > It's certainly an improvement in correctness, I just hate it. ;) > > > > One problem

[PATCH RFC xserver] os: Add a mutex to protect io buffers

://bugs.freedesktop.org/show_bug.cgi?id=99164 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99887 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- RFC: This is probably sub-optimal and broken in many places, but it seems to avoid the memory corruption (so far)... At leas

Re: [PATCH xserver] Xi: Hold the input lock when sending events

Hi, > Otherwise the output buffer will be accessed from different threads and > cause all sorts of nasty and painful memory corruptions. > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99164 > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99887 > Sign

[PATCH xserver] Xi: Hold the input lock when sending events

Otherwise the output buffer will be accessed from different threads and cause all sorts of nasty and painful memory corruptions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99164 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99887 Signed-off-by: Olivier Fourdan <of

Re: xserver 1.19.2 call for patches

Hi Michel, - Original Message - > On 20/02/17 06:44 PM, Olivier Fourdan wrote: > > - Original Message - > >> I'd like to do another 1.19 soonish, say middle of next week. > > > > That would be great if we could get to the bottom of the random > &

Re: xserver 1.19.2 call for patches

- Original Message - > I'd like to do another 1.19 soonish, say middle of next week. That would be great if we could get to the bottom of the random crashes that affect 1.19.x first. Good news is we now have a core file from downstream bug

[PATCH xserver] os: remove unused define MAX_TIMES_PER

Remove leftover from commit e10ba9e, MAX_TIMES_PER is not used anymore. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- os/io.c | 1 - 1 file changed, 1 deletion(-) diff --git a/os/io.c b/os/io.c index 5ba1e86..be85226 100644 --- a/os/io.c +++ b/os/io.c @@ -116,7 +116,6 @@

[PATCH xserver] Revert "xwayland: bump wayland-protocols version to 1.7"

This reverts commit 371ff0c969a38a0013688391bbd7375bc7b6f933. --- I'm really sorry, I got confused, pointer contraints does not require 1.7 and 1.1 was enough... While it's not a major issue as 1.7 is a released version, we still can revert this commit as it's not mandatory. Sorry again!

Re: xserver 1.19.2 call for patches

Hey Adam, > I'd like to do another 1.19 soonish, say middle of next week. If you've > got favorite patches you'd like to see included, please write their > sha1s on the back of a $50 bill and send them to me. > > Alternatively, reply to this email, or send a pull request. For Xwayland, I'd say:

[PATCH xserver] xwayland: bump wayland-protocols version to 1.7

Xwayland support for pointer locking in confinement requires wayland-protocols version 1.7 or later. Update the required version in configure.ac to match the minimal required version of wayland-protocols. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- configure.ac | 2 +-

Re: [PATCH xserver 2/2 v4] xwayland: Apply output rotation for screen size

Hey Adam, - Original Message - > On Wed, 2017-02-08 at 09:23 +0100, Olivier Fourdan wrote: > > Previously, we would swap the width/height of the Xwayland output based > > on the output rotation, so that the overall screen size would match the > > actual ro

[PATCH xserver 2/2 v4] xwayland: Apply output rotation for screen size

size being wrong in "xrandr -q" and the pointer being constrained in the wrong dimension with rotated with weston. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v3: Split the patch in two as there two issues.

Re: [PATCH xserver] xwayland: replace hardcoded function name with __func__ in error msg

Hey Peter, > > LGTM - Yo get rid of two \n along the way, but I think there were not > > needed in the first place so: > > oops. no, they're neeed so I added them back (and also to the instance where > it was missing). thanks Are they really needed? I looked at ErrorF() in the source tree and

[PATCH xserver v3 2/2] xwayland: Disable RR ConstrainCursorHarder()

limits on the pointer. Disable the ConstrainCursorHarder() handler set by RRScreenInit() to avoid the issue. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v3: Split the patch in two as there two issues. The second issue

[PATCH xserver v3 1/2] xwayland: CRTC should support all rotations

and reflections so that the configuration remains a valid xrandr setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v2: We don't need to support all rotatons and reflections, just one (RR_Rotate_0) and use it in the current

Re: [PATCH xserver] xwayland: replace hardcoded function name with __func__ in error msg

t; -ErrorF("create_output ENOMEM\n"); > +ErrorF("%s ENOMEM", __func__); > return NULL; > } > > -- > 2.9.3 LGTM - Yo get rid of two \n along the way, but I think there were not needed in the first place so: Reviewed-by: Olivier F

[PATCH xserver v2] xwayland: Support RR_Rotate_0 in rrGetInfo()

it in the current config for rrGetInfo() so that the configuration remains a valid xrandr setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v2: We don't need to support all rotatons and reflections, ju

[PATCH xserver] xwayland: Pretend we support all transformations

output protocol) so that the waylandsetup remains a valid xrandr setup. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99663 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-output.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-)

Re: [PATCH xwayland] xwayland: Add hack for FWXGA resolution #99574

modeinfo.width, modeinfo.height); > modeinfo.nameLength = strlen(name); > -- > 2.11.0 LGTM. Acked-by: Olivier Fourdan <ofour...@redhat.com> ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH] xwayland: Support horizontal resolutions not divisible by 8 #99574

Hi > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=99574 > > Signed-off-by: Svitozar Cherepii > --- > hw/xwayland/xwayland-cvt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/xwayland/xwayland-cvt.c b/hw/xwayland/xwayland-cvt.c > index

Re: glamor woes with nouveau

Hey! So I was wrong (again), this is not glamor_composite_choose_shader() failed which is the problem, the rendering issue comes from glamor_poly_fill_rect_gl() (the plain ackground is garbled, not the actual content, if that makes any sense). If I force glamor_poly_fill_rect_bail() from

[PATCH v2 xserver] glamor: Two pass won't work on memory pixmaps

ct. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99346 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v2: Bail out only on the specific case which would lead to the assertion failure otherwise glamor/glamor_render.c | 4 1 file changed, 4 insertions(+) diff --gi

Re: [PATCH xserver] glamor: keep gl_fbo and fbo consistent

> There is a fundamental logical problem with this patch though, because > glamor_upload_picture_to_texture() does: > > assert(glamor_pixmap_is_memory(pixmap)); > > which is basically priv->type == GLAMOR_MEMORY; > > So glamor_upload_picture_to_texture() clearly expects a pixmap of type >

Re: [PATCH xserver] glamor: keep gl_fbo and fbo consistent

gs.freedesktop.org/show_bug.cgi?id=99346 > Signed-off-by: Olivier Fourdan <ofour...@redhat.com> > --- > glamor/glamor_render.c | 8 > glamor/glamor_utils.h | 4 > 2 files changed, 12 insertions(+) > > diff --git a/glamor/glamor_render.c b/glamor/gl

[PATCH xserver] glamor: keep gl_fbo and fbo consistent

=99346 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- glamor/glamor_render.c | 8 glamor/glamor_utils.h | 4 2 files changed, 12 insertions(+) diff --git a/glamor/glamor_render.c b/glamor/glamor_render.c index e04dd21..a9ab971 100644 --- a/glamor/glamor_render.c +++ b/

Re: [PATCH xserver v2 5/5] xwayland: use _XWAYLAND_ALLOW_COMMITS property

Hi Pekka, - Original Message - > here is an update on the Weston side: > https://lists.freedesktop.org/archives/wayland-devel/2017-January/032712.html > > The related Weston patches series has shrunk from 24 to 3 patches as > lots of them have been merged. The stuff about

Re: glamor woes with nouveau

Hi, On 18 January 2017 at 10:27, Olivier Fourdan <four...@gmail.com> wrote: >> >> This is where it gets even more confusing, I cannot reproduce the >> issue using "Xephyr -glamor"... Not even with Xephyr running in >> Xwayland. > > And by that I mean

Re: glamor woes with nouveau

On 18 January 2017 at 10:10, Olivier Fourdan <four...@gmail.com> wrote: > Hi Eric > > On 17 January 2017 at 21:25, Eric Anholt <e...@anholt.net> wrote: >> >> It sounds like nouveau is failing at the getteximage/texsubimage cycle >> in the fallback path.

Re: glamor woes with nouveau

Hi Eric On 17 January 2017 at 21:25, Eric Anholt wrote: > > It sounds like nouveau is failing at the getteximage/texsubimage cycle > in the fallback path. X sometimes finds bugs in Mesa than our testcases > miss, because it frequently reads/writes subsets of a texture. In >

glamor woes with nouveau

Hi all, I am trying to investigate an issue with Xwayland that affects pixmap rendering only some hardware with nouveau (basically, older hardware). Initally, I started looking into this because of reported black icons in gtk2 (X11/Xwayland) apps in GNOME and RH bugzilla, and discovered that one

Re: [PATCH xserver v2 5/5] xwayland: use _XWAYLAND_ALLOW_COMMITS property

Hi, - Original Message - > On Fri, 2016-12-09 at 14:24 +0200, Pekka Paalanen wrote: > > From: Pekka Paalanen > > > > The X11 window manager (XWM) of a Wayland compositor can use the > > _XWAYLAND_ALLOW_COMMITS property to control when Xwayland sends > >

Re: Null pointer deref in FlushAllOutput with 1.19-rc1 ?

Hi Keith, > Olivier Fourdan <ofour...@redhat.com> writes: > > >> FlushAllOutput() in /usr/src/debug/xorg-server-20160929/os/io.c:612 > >> Dispatch() in /usr/src/debug/xorg-server-20160929/dix/dispatch.c:3491 > >> dix_main() in /usr/src/debug/xorg-ser

Re: [RFC xserver 0/3] Allow XWM to control Xwayland commits

Hey On 5 December 2016 at 22:43, Adam Jackson wrote: > (apologies for being so slow to get to this thread, this is great stuff) > > On Mon, 2016-11-28 at 15:47 +0200, Pekka Paalanen wrote: > [...] > > > Mind, I am mostly thinking this in Weston XWM terms, which draws the > >

Re: startx(1) low hanging fruit buglet for > 1 year in bugzilla

Hi, > Esteemed X11 developers, > > may I direct your attention to a shell scripting buglet in startx(1), as > reported in https://bugs.freedesktop.org/show_bug.cgi?id=91811 which > sits there for more than a year now? Fix included. This is very low > hanging fruit for improving the code. If the

Re: [RFC xserver 2/3] xwayland: fix 'buffer' may be used uninitialized warning

_screen->glamor) > buffer = xwl_glamor_pixmap_get_wl_buffer(pixmap); > +else > #endif > -if (!xwl_screen->glamor) > buffer = xwl_shm_pixmap_get_wl_buffer(pixmap); > > wl_surface_attach(xwl_window->surface, buffer, 0, 0); > -- > 2.7.3 >

Re: [RFC xserver 1/3] xwayland: refactor into xwl_window_post_damage()

w *xwl_window, *next_xwl_window; > + > + xorg_list_for_each_entry_safe(xwl_window, next_xwl_window, > + _screen->damage_window_list, > link_damage) { > +/* If we're waiting on a frame callback from the server, > + * don't attach a new buffer. */ > +if (xwl_window->frame_callback) > +continue; > + > +xwl_window_post_damage(xwl_window); > } > } > > -- > 2.7.3 Reviewed-by: Olivier Fourdan <ofour...@redhat.com> ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [RFC xserver 3/3] Xwayland: use _XWAYLAND_ALLOW_COMMITS property

Hi Pekka, > [...] > Patches 1 and 2 OTOH would be ready for merging on my behalf. Yes, I think the two first patches are fine. > Olivier asked about _NET_WM_SYNC_REQUEST - do you want me to fully > implement the basic sync protocol too before accepting this series? I was hoping/wondering if

[Pull request]: couple of fixes for xwayland

changes up to e1d30075c923f96a375895d74ea12a3c92a640c6: configure: Enable glamor when building just Xwayland (2016-11-30 09:47:43 +0100) Adam Jackson (1): configure: Enable glamor when building just Xwayland Olivier Fourdan

[PATCH xserver] xwayland: Fix use after free of cursors

the same xwindow, being either the one found by miXYToWindow() or the root window. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Tested-by: Vít Ondruch <vondr...@redhat.com> Tested-by: Satish Balay <ba...@fastma

Re: [PATCH xserver v3] xwayland: Fix use after free of cursors

check if the xwindow > > found by the regular miXYToWindow() is a child of the known last > > xwindow, so that multiple consecutive calls to xwl_xy_to_window() > > return the same xwindow, being either the one found by miXYToWindow() > > or the root window. > > &

Re: [RFC xserver 0/3] Allow XWM to control Xwayland commits

Hi Pekka, > this is probably the first time I'm sending patches for the xserver, so > pointing out API misuse, coding style issues etc. would be appreciated. The > last patch also has some XXX comments with questions. > > The first patch, refactoring, is not absolutely necessary (anymore - I

Re: [PATCH xserver v3] xwayland: Fix use after free of cursors

own last > xwindow, so that multiple consecutive calls to xwl_xy_to_window() > return the same xwindow, being either the one found by miXYToWindow() > or the root window. > > Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258 > Signed-off-by: Olivier Fourdan <ofou

Re: [PATCH xserver] xwayland: Fix use after free of cursors

> Sometimes, Xwayland will try to use a cursor that has just been freed, > leading to a crash when trying to access that cursor data either in > miPointerUpdateSprite() or elsewhere. > [...] Right, I think I have to withdraw this patch, because it probably doesn't fix the issue... I still

[PATCH xserver] xwayland: Fix use after free of cursors

is already the root window, so that the logic in CheckMotion() is preserved. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1385258 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --gi

Xwayland crash using a free cursor in 1.19

Hi Just a quick heads up, I have been trying to investigate random crashes in Xwayland, something that occurs very randomly and really hard to reproduce. It appears that, sometimes, Xwayland will try to use a pCursor that has just been freed, leading to a crash when trying to use that cursor

[PATCH xserver] xwayland: Remove MIPOINTER() definition

Not needed anymore now that mipointer exposes an API for that, miPointerInvalidateSprite() Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/hw/xwayland/xwayland-input.c b/hw/xwayland/xwayland-i

Re: [PATCH xwayland 0/7] Implement zwp_tablet v2

Hey Jason, Carlos, > Okay... I had some remote confusion: > > $ git remote -v > jason https://github.com/wayland-tablet/xserver.git (fetch) > > I picked the most recent branch there as a starting point, but it's > sensibly older than that. I take back these patches, will look into > merging

[PATCH xserver] glamor: restore vfunc handlers on init failure

we don't leave the CloseScreen() and DestroyPixmap() from glamor handlers in place. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1390018 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- glamor/glamor.c | 11 --- 1 file changed, 8 insertions(+), 3 deletions(-) diff

Re: Null pointer deref in FlushAllOutput with 1.19-rc1 ?

Hi > > Multiple Fedora 25 users running 1.19-rc1 are reporting a backtrace > > related to an InitFonts -> SendErrorToClient -> FlushAllOutput > > call chain. > > > > Since there is no trivial reproducer this is somewhat hard to debug, > > hence this mail. Anyone have a clue / hint ? See: > > >

[xserver PULL for 1.19] One more patch on top of Hans' pull request

nd enable touch devices (2016-10-26 14:16:42 +0200) -------- Olivier Fourdan (1): xwayland: Activate and enable touch devices hw/xwayland/xwayland-input.c | 7 --- 1 file changed, 4 insertions(

Re: [xserver PULL for 1.19 ] Various small fixes for 1.19

Hi, - Original Message - > Hi Adam, Keith, > > Here is a pull-req with various small fixes > (all with at least 1 Reviewed-by) which I've collected > for merging into 1.19: > > The following changes since commit d13cb974426f7f1110b0bdb08c4ebb46ff8975f7: > >ddx: add new call to

Re: Null pointer deref in FlushAllOutput with 1.19-rc1 ?

Hi, > Multiple Fedora 25 users running 1.19-rc1 are reporting a backtrace > related to an InitFonts -> SendErrorToClient -> FlushAllOutput > call chain. > > Since there is no trivial reproducer this is somewhat hard to debug, > hence this mail. Anyone have a clue / hint ? See: > >

[PATCH xserver] xwayland: Activate and enable touch devices

activate and enable touch devices just like we do for other input devices such as keyboard and pointer. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/hw/xwayland/xwayland-input.

[PATCH v2 xserver] glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpu

nd written at the correct location. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Reviewed-and-Tested-by: Michel Dänzer <michel.daen...@amd.com> --- v2: Fix typos in commit message Reformat as per Michel's revie

[PATCH RFC xserver] glamor: Fix pixmap offset for bitplane in glamor_copy_fbo_cpu

at the correct location. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97974 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- Note: This fixes the crash apparerntly and produces the expected output, as tested with xterm's contectual menu, the check boxes are

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

-if (xwl_seat->focus_window == NULL && xwl_seat->last_xwindow == ret) { > +if (sprite_check_lost_focus(sprite, ret)) { > sprite->spriteTraceGood = 1; > return sprite->spriteTrace[0]; > } > > -xwl_seat->last_xwindow = ret;

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

[Pull request]: couple of fixes for xwayland

to 0a20d5f8cb3f3f9a81b2795ae1865e72541022d4: xwayland: Clear up x_cursor on UnrealizeCursor() (2016-09-23 09:00:58 +0200) Olivier Fourdan (2): xwayland: handle EAGAIN on Wayland fd xwayland: Clear up x_cursor on UnrealizeCursor

[PATCH xserver] xwayland: Clear up x_cursor on UnrealizeCursor()

the seat's x_cursor has just been unrealized. To avoid this, walk through all the xwl_seats and clear up all x_cursor matching the cursor being unrealized. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-cursor.c | 10 ++ 1 file changed, 6 insertions

[PATCH xserver v2] xwayland: Clear up x_cursor on UnrealizeCursor()

the seat's x_cursor has just been unrealized. To avoid this, walk through all the xwl_seats and clear up all x_cursor matching the cursor being unrealized. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Reviewed-by: Jonas Ådahl <jad...@gmail.com> --- v2: Use xorg_list_for_each_ent

Re: [PATCH xserver] modesetting: Fix build without glamor

> There already was a fix for this posted a while ago, > but that still needs to be merged. Ah yeah, a couple of times even :) Cheers, Olivier ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info:

[PATCH xserver] modesetting: Fix build without glamor

oid the compilation error by putting th code that use it within an Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xfree86/drivers/modesetting/present.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/hw/xfree86/drivers/modesetting/present.c b/hw/xfree8

[PATCH xserver v4] xwayland: handle EAGAIN on Wayland fd

-off-by: Olivier Fourdan <ofour...@redhat.com> Reviewed-by: Daniel Stone <dani...@collabora.com> --- v2: oops, need to poll() on EAGAIN between retries v3: Mostly a rewrite, non-blocking on poll() v4: Check for EINTR after poll() and add R-b from Daniel hw/xwayland/xwa

Re: [PATCH xserver v3] xwayland: handle EAGAIN on Wayland fd

Hi Pekka, > all the rationale in this commit message looks good to me, just some > things I'd like to ask more about. > > > What this patch does is to avoid dispatching to the Wayland file > > descriptor until it becomes available for writing again, while at the > > same time continue processing

[PATCH xserver v3] xwayland: handle EAGAIN on Wayland fd

-off-by: Olivier Fourdan <ofour...@redhat.com> --- v2: oops, need to poll() on EAGAIN between retries v3: Mostly a rewrite, non-blocking on poll() hw/xwayland/xwayland.c | 34 +++--- hw/xwayland/xwayland.h | 1 + 2 files changed, 32 insertions(+), 3 deletions(-)

Re: weird Xwayland and compositor deadlock issue [WAS: [PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully]

Hi Pekka, - Original Message - > Hi Olivier, > > I don't have any solution for you. The interactions between the Wayland > compositor and Xwayland are known to be very easily deadlockable IIRC. I > believe the only thing you can do is ensure no such case can ever > occur, which is very

Re: weird Xwayland and compositor deadlock issue [WAS: [PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully]

Hi all - Original Message - > wl_display_flush() can fail with EAGAIN and Xwayland would make this a > fatal error. > > Handle the usual EAGAIN and EINTR gracefully so that Xwayland doesn't > die for so little. Right, I am running out of ideas... So the approach of using poll() to wait

[PATCH xserver v2] xwayland: handle EAGAIN and EINTR gracefully

wl_display_flush() can fail with EAGAIN and Xwayland would make this a fatal error. Handle the usual EAGAIN and EINTR gracefully so that Xwayland doesn't die for so little. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1278159 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> -

[PATCH xserver] xwayland: handle EAGAIN and EINTR gracefully

wl_display_flush() can fail with EAGAIN and Xwayland would make this a fatal error. Handle the usual EAGAIN and EINTR gracefully so that Xwayland doesn't die for so little. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1278159 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> -

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

patch does > > improve things for e.g. downstream bug > > https://bugzilla.redhat.com/show_bug.cgi?id=1373451 That particular bug is possibly a leak of cursors in Qt, but still, there is a weakness in Xwayland. so, weighing the pros and cons of this patch, FWIW: Reviewed-by: Olivi

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

pixmap->devKind, > > > format); > > > - > > > - wl_shm_pool_destroy(pool); > > > - > > > -return xwl_pixmap->buffer; > > > +return xwl_pixmap_get(pixmap)->buffer; > > > } > > > > >

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

gt; - > > -wl_shm_pool_destroy(pool); > > - > > -return xwl_pixmap->buffer; > > +return xwl_pixmap_get(pixmap)->buffer; > > } > > > > Bool > > Hi Rui, > > the idea here looks fine to me. > > However, I've been

Missing Xwayland patch for X server 1.19

Hi Peter, Adam, Do you think we could land Rui's patch for Xwayland for 1.19?: https://patchwork.freedesktop.org/patch/95244/ It's been reviewed by Daniel and tested by myself (and others) for some time. If needed, I can prepare a pull request if that's more convenient for you. Thanks Olivier

Backporting Xwayland fixes to 1.18.x

Hi, I have a few fixes in server-1.18-branch cherry-picked from master for Xwayland here: git://people.freedesktop.org/~ofourdan :server-1.18-backports (https://cgit.freedesktop.org/~ofourdan/xserver/log/?h=server-1.18-backports) These contains several fixes from master that can be

Re: [PATCH xserver] wayland: Emulate crossing for native window

found X window and compare against the new one, and > if they match then it means the pointer has left an Xwayland window for > a native Wayland surface, only in this case fake the crossing to the > root window. > > Signed-off-by: Olivier Fourdan <ofour...@redhat.com> > -

[PATCH xserver] xwayland: Avoid double free of RRCrtc and RROutput

-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-output.c | 12 +--- hw/xwayland/xwayland.c| 2 +- hw/xwayland/xwayland.h| 2 ++ 3 files changed, 12 insertions(+), 4 deletions(-) diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-ou

[PATCH xserver] present: Free the fake_present OsTimerPtr

/lib/libc-2.24.so) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97065 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- present/present_fake.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/present/present_fake.c b/present/present_fake.c index 4

[PATCH xserver] xwayland: Plug memleak in frame callbacks

The frame callback set up via wl_surface_frame() needs to be freed with wl_callback_destroy() or we'll leak memory. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=97065 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-cursor.c | 2 ++ hw/xwayland/xway

Re: Override redirect windows with keyboard grabs on Xwayland

Hi Adam, > > That mechanism would probably not work as is with O-R windows for a > > couple of reasons: > > Your descriptions here seem to assume the inability to fix the > compositor, which to me seems... insane? No, I did not assume this, but I find focus management in X11 to be quite

Re: Override redirect windows with keyboard grabs on Xwayland

Hey Adam, > This feels a lot like any other "app wants attention" case where you > should just get a pulsing button or bouncing icon in the taskbar. The > o-r window might be mapped and focused from Xwayland's perspective but > there's nothing compelling wayland to actually show or focus it >

Re: [PATCH xserver] xwayland: Process queued events before making wayland mods effective

e_mods = mods_depressed & XkbAllModifiersMask; > +new_state->locked_mods = mods_locked & XkbAllModifiersMask; > +XkbLatchModifiers(dev, XkbAllModifiersMask, > + mods_latched & XkbAllModifiersMask); > > XkbC

[PATCH xserver] wayland: Emulate crossing for native window

for a native Wayland surface, only in this case fake the crossing to the root window. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 15 ++- hw/xwayland/xwayland.c | 3 ++- hw/xwayland/xwayland.h | 1 + 3 files chang

Re: [PATCH v3 xserver] xwayland-input: Fake crossing to rootwin

- Original Message - > On Tue, Jun 21, 2016 at 01:54:35PM +0200, Olivier Fourdan wrote: > > This partially reverts commit c1565f3. > > > > When the pointer moves from an X11 window to a Wayland native window, > > no LeaveNotify event is emitted which can

[PATCH v3 xserver] xwayland-input: Fake crossing to rootwin

surface. Restore the XYToWindow() handler in xwayland-input that was previously removed with commit c1565f3 and use that handler to pretend that the pointer entered the root window in this case so that the LeaveNotify event is emitted. Signed-off-by: Olivier Fourdan <ofour...@redhat.com>

[PATCH RFC v2 xserver] xwayland-input: Fake crossing to rootwin

surface. Restore the XYToWindow() handler in xwayland-input that was previously removed with commit c1565f3 and use that handler to pretend that the pointer entered the root window in this case so that the LeaveNotify event is emitted. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Bu

Re: [PATCH xserver 2/3] xwayland: Use correct labels when initializing pointer valuators

Absolute)) > return BadValue; > > -- > 2.8.3 Looks right to me. Reviewed-by: Olivier Fourdan <ofour...@redhat.com> Cheers, Olivier ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

Re: [PATCH xserver 3/3] xwayland: Expose all NBUTTONS buttons on the pointer

ot; on the xwayland pointer would list only 3 buttons whereas with that patch I get the 10 buttons. Reviewed-by: Olivier Fourdan <ofour...@redhat.com> Cheers, Olivier ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel

Override redirect windows with keyboard grabs on Xwayland

Hi all, First of all, sorry for cross posting, but I am not really sure where the issue is to be addressed... I am looking into https://bugs.freedesktop.org/show_bug.cgi?id=96547 and concluded this is actually the same as https://bugzilla.gnome.org/show_bug.cgi?id=752956 Basically, long

<    1   2   3   4   5   6   >