Re: [PATCH xserver 1/3] xwayland: Add hook to check wl interface for glamor

Hi Lyude, On Wed, May 30, 2018 at 9:31 PM, Lyude Paul wrote: > NAK. I'm starting to see the problems with this approach I originally hit now. > > So: there's some unexpected catches when it comes to EGL client extensions. On > a system using glvnd with the nvidia driver, the EGL client extension

[PATCH xserver 3/3] xwayland: Check required interfaces for EGLstreams

Use the newly added “has_wl_interface” hook to check availability of “wl_eglstream_display” and “wl_eglstream_controller” interfaces prior to enable glamor with EGL Streams backend. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 21 + 1 file

[PATCH xserver 1/3] xwayland: Add hook to check wl interface for glamor

Add an optional egl_backend callback to check that the required Wayland interfaces are available. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor.c | 9 + hw/xwayland/xwayland.c| 4 hw/xwayland/xwayland.h| 7 +++ 3 files changed, 20 insertions

[PATCH xserver 2/3] xwayland: Check required interfaces for GBM backend

Use the newly added “has_wl_interface” hook to check availability of “wl_drm” interface prior to enable glamor with GBM backend. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-gbm.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/hw/xwayland/xwayland-glamor

Re: [PATCH xserver] Xwayland: Enable EGL backend automatically

Hi Lyude, On Tue, May 29, 2018 at 7:54 PM, Lyude Paul wrote: > On Mon, 2018-05-28 at 09:11 +0200, Olivier Fourdan wrote: > > [...] > I agree that we need to check for the protocol availability of course, yet > it doesn't mean we should ditch this patch. > > Imagine (I say i

[PATCH v2 xserver] Xwayland: Enable EGL backend automatically

Check for "EGL_MESA_platform_gbm" in the avaiable EGL extensions, and try automatically EGL stream if not present. The command line options “-eglstream” is kept for compatibility to force the use of the EGL streams backend. Suggested-by: Ray Strode Signed-off-by: Olivier Fourdan --

Re: [PATCH] xwayland: fix typo in non-modifier fallback path

modifier = DRM_FORMAT_MOD_INVALID; > -strides[0] = gbm_go_get_stride(xwl_pixmap->bo); > +strides[0] = gbm_bo_get_stride(xwl_pixmap->bo); > offsets[0] = 0; > #endif > > -- > 2.17.0 > > Huhu, indeed! First introduced with commit c8c276c95 then lat

Re: [PATCH xserver] Xwayland: Enable EGL backend automatically

Hi Pekka, On 28 May 2018 at 09:24, Pekka Paalanen wrote: > do not use strstr() for matching extensions strings. It does a > sub-string match, which may not be what you want. What if there was an > extension called "platform_gbm_unixmem" or such? > The substring match is

Re: [PATCH xserver] Xwayland: Enable EGL backend automatically

Hey Luyde, On Fri, May 25, 2018 at 7:54 PM, Lyude Paul wrote: > > NAK, unfortunately this check isn't going to be enough, see: > > 2018-05-24 15:44:34 jadahl Lyude: you can also look at the globals > sent > out by the compositor > 2018-05-24 15:44:52 Lyude jadahl:

[PATCH xserver] Xwayland: Enable EGL backend automatically

Check for "platform_gbm" in the avaiable EGL extensions, and enable automatically EGL stream if not present. The command line options “-eglstream” is kept for compatibility to force the use of the EGL streams backend. Suggested-by: Ray Strode <rstr...@redhat.com> Signed-off-by:

[PATCH v2 xserver 4/5] xwayland: Do not disable glamor if eglstream failed

y want to enable EGL stream on GPU which support it. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v2: Try GBM only if EGL streams actually failed (or wasn't requested) hw/xwayland/xwayland.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/hw/xwaylan

[PATCH xserver 0/5] Xwayland fixes wrt eglstream support

” to the Xwayland command line and Xwayland would adapt automatically and play nice. This the goal of that series of patches (plus one little code cleanup). Cheers, Olivier Olivier Fourdan (5): xwayland: Allow "-eglstream" option xwayland: "EGL_EXT_device_base" required for

[PATCH xserver 4/5] xwayland: Do not disable glamor if eglstream failed

y want to enable EGL stream on GPU which support it. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland.c | 8 +++- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c index cc16edf27..5c61b65dc 100644 --

[PATCH xserver 3/5] xwayland: process Wayland events after adding screen

ayland (_start) (EE) (EE) Fatal server error: (EE) Caught signal 6 (Aborted). Server aborting (EE) Aborted (core dumped) Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland.c | 4 1 file changed, 4 insertions(+) diff --git a/hw/xway

[PATCH xserver 1/5] xwayland: Allow "-eglstream" option

, obviously without EGL stream support this has no effect. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/hw/xwayland/xwayland.c b/hw/xwayland/xwayland.c index 1d6b49979..b4049d2cc

[PATCH xserver 5/5] xwayland: small xdg_output cleanup

Make xwl_output_get_xdg_output() private, it doesn't need to be available elsewhere. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-output.c | 4 +++- hw/xwayland/xwayland.h| 1 - 2 files changed, 3 insertions(+), 2 deletions(-) diff --git a/hw/xw

[PATCH xserver 2/5] xwayland: "EGL_EXT_device_base" required for eglstream

Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-glamor.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c index cdca072ed..f543f321d 100644 --- a/hw/xwayland/xwayland-glamor.c +++ b/hw/xwayland/x

Re: [RFC xserver] xwayland: persistent window struct on present

ruct xwl_screen { > CloseScreenProcPtr CloseScreen; > RealizeWindowProcPtr RealizeWindow; > UnrealizeWindowProcPtr UnrealizeWindow; > +DestroyWindowProcPtr DestroyWindow; > XYToWindowProcPtr XYToWindow; > > struct xorg_list output_list; > @@ -172,26 +17

Re: [PATCH xserver] present: in get_ust_msc hook of wnmd provide CRTC as argument

} > window_priv->crtc = crtc; > } > @@ -565,7 +569,7 @@ present_wnmd_pixmap(WindowPtr window, > > target_crtc = present_wnmd_get_crtc(screen_priv, window); > > -ret = present_wnmd_get_ust_msc(screen, window, , _msc); > +ret = present_wnmd_get_ust_msc(screen, wind

Re: [PATCH xserver] present: fix msc offset calculation in window mode

Hi, On 20 April 2018 at 18:11, Michel Dänzer wrote: > On 2018-04-20 05:10 PM, Roman Gilg wrote: > > Instead of getting the current msc value from the window, which might be > > different to old one directly take the last saved msc value saved in > > the window_priv struct.

Re: [PATCH xserver v2] xwayland: avoid using freed xwl_window on unrealize

Hey, On Thu, Apr 19, 2018 at 5:33 PM, Olivier Fourdan <ofour...@redhat.com> wrote: > > But there are still oddities, like some window remaining black for like > 2~3 seconds after re-mapping. > > Closing the skypeforlinux toplevel and restoring it by running it again > t

Re: [PATCH xserver v2] xwayland: avoid using freed xwl_window on unrealize

Hi Daniel, On Thu, Apr 19, 2018 at 5:24 PM, Daniel Stone wrote: > [...] > The callback is passed as an argument to the function directly, so you > could just destroy that instead. > Sure, but that wouldn't solve the problem which is the callback occurs after the

Re: [PATCH xserver v2] xwayland: avoid using freed xwl_window on unrealize

Hi, On Thu, Apr 19, 2018 at 5:05 PM, Olivier Fourdan <ofour...@redhat.com> wrote: > Looks like we're not done yet :/ > > I'll try that other patch I sent and see if that makes a difference here, > could be related according to the backtrace I guess...

Re: [PATCH xserver v2] xwayland: avoid using freed xwl_window on unrealize

Hi, On Thu, Apr 19, 2018 at 9:15 AM, Olivier Fourdan <four...@gmail.com> wrote: > Sure, I've sent a new patch to do that, but I reckon this can wait after > the release, we might leak a frame callback in some cases (although > valgrind did not really complain yet), but we won'

Re: [PATCH xserver v2] xwayland: avoid using freed xwl_window on unrealize

Hi Roman, On 18 April 2018 at 20:34, Roman Gilg wrote: > > I believe this check should be ORed with xwl_window->window == window. > Otherwise in case the top parent window is unrealized first, > xwl_window->present_window != window holds here and afterwards >

[PATCH xserver] xwayland: Clean up all frame callbacks

Regardless of the order we un-realize windows. Suggested-by: Roman Gilg <subd...@gmail.com> Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-present.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland-present.c b

[PATCH xserver v2] xwayland: avoid using freed xwl_window on unrealize

82df2ce3 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- v2: Free queued buffers and events as well, not none is left after unrealize. That new patch gives no "invalid read" no more :) hw/xwayland/xwayland-input.c | 2 +- hw/xwayland/xwayland-present.c | 34 +++

Re: [PATCH xserver] xwayland: avoid using freed xwl_window on unrealize

) by 0x554BFD: Dispatch (dispatch.c:479) by 0x558C65: dix_main (main.c:276) by 0x79F81BA: (below main) (libc-start.c:308) That's what I meant by “elaborate from there” in my previous post :) Cheers, Olivier On Wed, Apr 18, 2018 at 3:29 PM, Olivier Fourdan <ofour...@redhat.com>

[PATCH xserver] xwayland: avoid using freed xwl_window on unrealize

commit 82df2ce3 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 2 +- hw/xwayland/xwayland-present.c | 22 + hw/xwayland/xwayland.c | 60 -- hw/xwayland/xwayland.h | 4 +-- 4 files chang

Re: Quick heads-up, Xwayland present code causing memory corruption and crashes

Hi Roman, Thanks for your reply! On 18 April 2018 at 13:02, Roman Gilg <subd...@gmail.com> wrote: > On Wed, Apr 18, 2018 at 11:25 AM, Olivier Fourdan <ofour...@redhat.com> > wrote: > > This is a quick heads up, I was experiencing random crashes in Xwayland > >

Quick heads-up, Xwayland present code causing memory corruption and crashes

Hi all, This is a quick heads up, I was experiencing random crashes in Xwayland (very annoying in gnome-shell and it takes gnome-shell and the entire session with it). while running skype with current Xwayladn from 1.20 rc4. Running Xwayland in valgrind yields a lot of memory corruption when

Re: [PATCH xserver] modesetting: Move GBM code inside #ifdef GLAMOR_HAS_GBM

f GLAMOR_HAS_GBM > if (drmmode->glamor) { > +uint32_t format; > + > +if (drmmode->scrn->depth == 30) > +format = GBM_FORMAT_ARGB2101010; > +else > +format = GBM_FORMAT_ARGB8888; > + > #ifdef GBM_BO_WITH_M

[PATCH xserver] xwayland: Fix build without glamor

Present support in Xwayland relies on glamor, make sure Xwayland can be built without glamor by moving references to Present code inside the conditional GLAMOR_HAS_GBM. Reported-by: Matt Turner <matts...@gmail.com> Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland

Re: [PATCH xserver] modesetting: Move GBM code inside #ifdef GLAMOR_HAS_GBM

Hi, On Mon, Apr 16, 2018 at 8:37 AM, Matt Turner wrote: > Fixes a compilation error without Glamor. > > Bugzilla: https://bugs.gentoo.org/653288 > Signed-off-by: Matt Turner > --- > Unfortunately, there's more: Xwayland fails to link without Glamor. >

Re: [ANNOUNCE] xorg-server 1.19.99.904

Hey Adam, On Wed, Apr 11, 2018 at 4:40 PM, Adam Jackson <a...@redhat.com> wrote: > On Wed, 2018-04-11 at 09:49 +0200, Olivier Fourdan wrote: > > > What are the risks of landing it? It would break for hardware/driver > > which are not supported yet anyway? > > The co

Re: [ANNOUNCE] xorg-server 1.19.99.904

Hi Adam, [Re-sending to xorg-devel where this was intended, sorry!] On 10 April 2018 at 21:57, Adam Jackson wrote: > Another batch of cleanups and fixes, mostly in glamor and DRI3. > > At this point the only outstanding major feature for 1.20 that hasn't > landed yet is

Re: [PATCH xserver v3 3/3] modesetting: Actually get framebuffer ID

y: Daniel Stone <dani...@collabora.com> > Reported-by: Olivier Fourdan <ofour...@redhat.com> > --- > hw/xfree86/drivers/modesetting/drmmode_display.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c &

Re: [PATCH xserver 1/2] modesetting: Don't reuse iterator in nested loop

On Thu, Apr 5, 2018 at 3:58 PM, Daniel Stone wrote: > drmmode_crtc_set_mode has a loop nested inside another loop, where both > of them were using 'i' as the loop iterator. Rename it to avoid an > infinite loop. > > Signed-off-by: Daniel Stone >

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

Hi Mario, On Wed, Mar 28, 2018 at 7:42 PM, Mario Kleiner wrote: > The approach in the patch looks good to me, same as we use in weston. > I'll test in a few hours and let you know. > Can you try with Luis-Francis's series (2 patches):

Re: [PATCH xserver 2/2] modesetting: Fix reported size when using atomic modesetting

crtc->mode.VDisplay); > > if (ret == 0) > ret = drmModeAtomicCommit(ms->fd, req, flags, data); > -- > 2.14.3 > Looks good to me *but* this is not sufficient because do_queue_flip_on_crtc() calls drmmode_crtc_set_fb() w

Re: [PATCH xserver 1/2] modesetting: Ignore alpha channel when importing BOs for modesetting

@@ drmmode_bo_import(drmmode_ptr drmmode, drmmode_bo *bo, > memset(modifiers, 0, sizeof(modifiers)); > > format = gbm_bo_get_format(bo->gbm); > +format = get_opaque_format(format); > for (i = 0; i < num_fds; i++) { > handl

[PATCH xserver] modesettings: Use actual crtc position for pageflip

Otherwise the same content is shown on all outputs. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xfree86/drivers/modesetting/pageflip.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xfree86/drivers/modesetting/pageflip.c b/hw/xfree86/drivers/modes

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

Hi, On Wed, Mar 28, 2018 at 2:59 PM, Olivier Fourdan <ofour...@redhat.com> wrote: > > It definitely improves the situation yet there is probably more to it > because with this added on top of the current git master, only the laptop > output works, the external monitor connec

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

Hi, On Wed, Mar 28, 2018 at 9:03 AM, Olivier Fourdan <ofour...@redhat.com> wrote: > On Wed, Mar 28, 2018 at 5:58 AM, Louis-Francis Ratté-Boulianne < > l...@collabora.com> wrote: > >> Could you try with the following patch and let me know how things are

[PATCH xserver] automake: Fix 'make dist'

Automake would skip a few meson files that would prevent to build with meson a dist file previously generated by automake. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- Makefile.am | 3 +++ 1 file changed, 3 insertions(+) diff --git a/Makefile.am b/Makefile.am index 5dd

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

Hi, On Wed, Mar 28, 2018 at 5:58 AM, Louis-Francis Ratté-Boulianne < l...@collabora.com> wrote: > Could you try with the following patch and let me know how things are > working out: > > https://gitlab.collabora.com/lfrb/xserver/commit/d26b45afc19547ab3ff689 > 581db2b01abb4e1ed2 > That requires

Re: [PATCH xserver 02/12] man: s/__/@/g

Hi, On Tue, Mar 27, 2018 at 12:42 AM, Adam Jackson wrote: > A cosmetic change for automake (though we have to replicate some of > xorg-macros.m4 in manpages.am now), but meson's configure_file() wants > @-delimited strings. > [...] Note sure if it's related but the builds

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

Hi, On Mon, Mar 26, 2018 at 7:54 PM, Mario Kleiner wrote: > [...] > I haven't had time to retest with the latest patch on master of Adam > "modesetting: Fix up some XXX from removing GLAMOR_HAS_DRM_*" > yet, so maybe that makes a positive difference? My testing was

Re: [PATCH xserver] modesetting: Fix page flipping under DRI 3.2.

Hi On Wed, Mar 21, 2018 at 10:09 PM, Mario Kleiner wrote: > Thanks. However, seems we may have one more problem with the new code > on slightly older < gen 9 Intel hw. Either that, or something is > botched on my system atm., after pulling in all kind of updates to >

Re: [PATCH xserver] xwayland: Fix backwards need_rotate logic (v2)

want. > > v2 (Daniel Stone): > - Fix output_get_new_size so that it doesn't flip the dimensions when >need_rotate is false. > > Signed-off-by: Jason Ekstrand <ja...@jlekstrand.net> > Reviewed-by: Daniel Stone <dani...@collabora.com> > Cc: Olivier Fourdan &

Re: [PATCH xserver] xwayland: Don't process cursor warping without an xwl_seat

Hi Lyude, On Mon, Feb 5, 2018 at 11:22 PM, Lyude Paul wrote: > Unfortunately, on my machine Xwayland immediately crashes when I try to > start it. gdb backtrace: > > #0 0x774f0e79 in wl_proxy_marshal () from > target:/lib64/libwayland-client.so.0 > #1

[PATCH xserver] xwayland: place a manual redirect on windows

dan...@fooishbar.org> Signed-off-by: Olivier Fourdan <ofour...@redhat.com> Reviewed-by: Daniel Stone <dan...@fooishbar.org> --- R-b was given by Daniel on irc on #wayland. This goes along with the other patch: https://patchwork.freedesktop.org/patch/200439/ hw/xwayland/xwayland.c | 5 +++

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

son <a...@nwnk.net> and Daniel Stone <dan...@fooishbar.org> for finding the root cause the issue. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/hw/xwayland/xwayland.c b/hw/xway

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

On Wed, Jan 24, 2018 at 5:17 PM, Adam Jackson <a...@nwnk.net> 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 tr

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 <ofour...@redhat.com> 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? > > Becaus

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

Hi Daniel, On Tue, Jan 23, 2018 at 11:15 AM, Daniel Stone wrote: > Ooh. serialNumber == 1 means it's the root pixmap, which will actually > be uselessly empty. It would be interesting to see how we've ended up > here: it would have to be a top-level window which a) was

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

Hey Adam, On 22 January 2018 at 19:57, Adam Jackson <a...@nwnk.net> wrote: > On Thu, 2018-01-18 at 11:41 +0100, Olivier Fourdan wrote: > > This is a rare occurrence of a crash in Xwayland for which I don't have > > the reproducing steps, just a core file. > > > &

Re: [RFC xserver 1/1] xwayland: reduce over-damage

Hi Pekka, On 22 January 2018 at 14:34, Pekka Paalanen wrote: > On Wed, 20 Dec 2017 13:18:45 +0200 > Pekka Paalanen wrote: > > > From: Pekka Paalanen > > > > If an X11 app draws a little here, some there, and

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

Hi Daniel, On Thu, Jan 18, 2018 at 12:22 PM, Daniel Stone wrote: > Odd; how could we have a realized 0x0 window which also has damage? I > Hehe, yeap, I had the same question, but didn't find the answer... :) > wonder if this isn't actually a UAF where the xwl_window

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

map is created for pixmaps of size 0×0. Avoid the NULL pointer dereference by checking the actual “xwl_pixmap” value in both glamor and shm implementations of pixmap_get_wl_buffer() and return a NULL buffer if there is no “xwl_pixmap”. Signed-off-by: Olivier Fourdan <ofour...@redhat.com>

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

weston and mutter/gnome-shell, a mode X×Y at scale 2 will still show up as X×Y in xrandr. Cheers, Olivier On Thu, Sep 7, 2017 at 5:43 PM, Olivier Fourdan <ofour...@redhat.com> wrote: > The xdg-output protocol aims at describing outputs in way which is > more in line with the concept

[RFC PATCH xserver] xwayland: avoid race condition on new keymap

. Apply the new keymap to the master keyboard as long as there's one. Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=791383 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- Note: screencast of the problem here: https://bugzilla.gnome.org/attachment.cgi?id=365231 “RFC” b

Re: [PATCH xserver 6/6] os: Remove unused OsRegisterSigWrapper

On Wed, Dec 13, 2017 at 5:15 PM, Adam Jackson <a...@redhat.com> wrote: > On Wed, 2017-12-13 at 16:21 +0100, Olivier Fourdan wrote: > > > Note that xf86-video-intel/src/sna/sna_accel.c makes use of > > OsRegisterSigWrapper() and will need updating. > > Ngh. Okay, mer

Re: [PATCH xserver 6/6] os: Remove unused OsRegisterSigWrapper

/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel Note that xf86-video-intel/src/sna/sna_accel.c makes use of OsRegisterSigWrapper() and will need updating. Anyway, LGTM. 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: [PATCH xserver 5/6] kdrive: remove KdSignalWrapper etc.

__________ > 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 LGTM. 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: [PATCH xserver 4/6] xfree86: remove xf86CaughtSignal etc.

ns is as follows: > > > > - > - > -Bool xf86CaughtSignal(); > - > - > - Returns TRUE if the server has caught a signal, > - and FALSE otherwise. > - > - > - > > > > -- > 2.14.3 > > ___ > 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 LGTM. 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: [PATCH xserver 3/6] os: Make OsSignalHandler ask for core dumps for signo != SIGQUIT

elopment > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x.org/mailman/listinfo/xorg-devel If we set Coredump to TRUE here for all signals but SIGQUIT, do we still need the “-core” command line option? Anyway, LGTM. 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: [PATCH xserver 2/6] xfree86: Remove xf86InterceptSignals

itch (VM86_TYPE(retval)) { > case VM86_UNKNOWN: > -- > 2.14.3 > > ___ > 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 I can't tell whether or not this happens in practice, but for the code part, this is: 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: [PATCH xserver 1/6] xfree86: Remove xf86InterceptSigIll

ept < 0)) { > *xf86SignalIntercept = signo; > return 0; /* continue */ > -- > 2.14.3 > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https:/

[PATCH xserver] dix: avoid deferencing NULL PtrCtrl

dereference will occur leading to a crash of Xwayland. Check whether the PtrCtrl is not NULL in ProcGetPointerControl() and return the default control values oterhwise, to avoid the NULL pointer dereference. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1519533 Signed-off-by: Olivier Fourdan

Re: [PATCH xwayland] xwayland: Keep separate variables for pointer and tablet foci

stylus focus, and to correctly translate surface-local coordinates > > to root coordinates, this can be done using a different variable. > > > > Signed-off-by: Carlos Garnacho <carl...@gnome.org> > > Makes sense: > > Acked-by: Jason Gerecke <jason.gere...@wacom.

Re: [PATCH RFC xserver] xwayland: List all wl_output::mode(s) in xrandr

Hey, > > Say, xwl_screen size is 1600x1200, RandR "sets" 800x600, and suddenly > > all Xwayland wl_surfaces start using wp_viewport to set 2x up-scaling? > > I.e. X11 window size that is 800x600 will produce a 800x600 wl_buffer, > > but wp_viewport makes the wl_surface 1600x1200. I think visually

Re: [PATCH RFC xserver] xwayland: List all wl_output::mode(s) in xrandr

Hi Pekka, > > [...] > > > > Basically, in downstream RH bug 1289714 [1], Robert Mader (cc'ed) is > > running some proof of concept to see how he can improve the support > > for older games in Xwayland. > > Ooh, exciting! I had a quick glimpse through the thread. > > > So this patch here is

Re: [PATCH RFC xserver] xwayland: List all wl_output::mode(s) in xrandr

Hi Pekka, > do you also plan to let Xwayland change the mode? If not, what's the > benefit of this? Yeah, sorry, I didn't give all the details on why this RFC patch, my bad. Basically, in downstream RH bug 1289714 [1], Robert Mader (cc'ed) is running some proof of concept to see how he can

[PATCH RFC xserver] xwayland: List all wl_output::mode(s) in xrandr

Xwayland would only list the current wl_output mode in xrandr, even though multiple modes might be advertised by the Wayland compositor. List all available modes listed by the Wayland compositor using wl_output::mode in XrandR. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> ---

Re: Xwayland fatal error when Wayland output disappears

Hi, On 23 November 2017 at 16:13, Olivier Fourdan <four...@gmail.com> wrote: > FWIW, it seems we have that issue with more than just wl_output, in > downstream bug 1516859 [1] this occurs with wl_seat on VT switch as well. > > That's pretty easy to reproduce, issue severa

Re: Xwayland fatal error when Wayland output disappears

Hi Pekka, On 27 October 2017 at 08:01, Pekka Paalanen wrote: > there is a known race around Wayland globals. If the Wayland server > adds and removes a global in a very short time, it may succeed to > remove the global (wl_output) before all clients have processed the >

Re: [PATCH xserver 0/6] Signal handling cleanups

Hi Adam, > I started writing a review of Olivier's patch and got sidetracked. I > can't really think of a good reason _not_ to generate a core if > possible, even for xfree86, and I think things look a lot simpler if we > [...] That's definitely a move in the right direction imho, yet on further

[PATCH xserver] xwayland: Give up “cleanly“ on Wayland socket errors

. Instead of using FatalError() on Wayland socket errors, give up cleanly to avoid dumping core files when "-core" is used. See also: https://bugzilla.gnome.org/show_bug.cgi?id=790502 and: https://bugzilla.gnome.org/show_bug.cgi?id=789086 Signed-off-by: Olivier Fourdan <ofour...@redha

Re: [PATCH xserver] xwayland: Restore default signal handlers

that the usual > signals (SIGSEGV, SIGABRT, SIGILL, etc.) will possibly generate a core > file (depending on the OS configuration of course). > > See also: https://bugzilla.gnome.org/show_bug.cgi?id=790502 > and: https://bugzilla.gnome.org/show_bug.cgi?id=789086 > > Signed-off-b

[PATCH xserver] xwayland: Restore default signal handlers

l possibly generate a core file (depending on the OS configuration of course). See also: https://bugzilla.gnome.org/show_bug.cgi?id=790502 and: https://bugzilla.gnome.org/show_bug.cgi?id=789086 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland.c | 19 ++

Re: [RFC PATCH xserver] xwayland: Fix non-argb cursor conversion

Hi all, Anyone to review/comment on this patch below? It seems to fix the issue wit hte reproducer from the bug, but I dunno if this is right fix... Thanks Olivier > Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012 > Signed-off-by: Olivier Fourdan <ofour...@redhat.com> &

Re: [PATCH xserver 3/8] xwayland: Stop printing the EGL version

t's debatable, weston for example logs a "Spawned Xwayland server, pid ..." when starting Xwayland anyway) > Signed-off-by: Adam Jackson <a...@redhat.com> Acked-by: Olivier Fourdan <ofour...@redhat.com> > --- > hw/xwayland/xwayland-glamor.c | 4 > 1 file ch

Re: Xwayland fatal error when Wayland output disappears

Hi, Could you please post a backtrace, breaking on xwl_log_handler() ? Another interesting data to capture would be the WAYLAND_DEBUG logs (between Xwayland and gnome-shell) wl_registry_bind() occurs when actually binding to an interface, which in the case of wl_output occurs when adding a new

Re: Pull request for server-1.19.branch fixes ?

Hi, > > It appears the Xserver in 1.19 branch is missing quite a few fixes from > > master, so I prepared a branch back-porting fixes at > > Hi, please add this to the list: > > commit fbd80b2c8ebe9fd41229dc5438524d107c071ff1 > Author: Dawid Kurek > Date: Thu

[RFC PATCH xserver] xwayland: Fix non-argb cursor conversion

Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=103012 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- Note: I am not familiar with this so I have no idea whether or not the fix is correct (thus the RFC), but it does fix the test case provided in bug 103012. hw/xwayland/xw

Re: Pull request for server-1.19.branch fixes ?

ate offsets xfree86/modes: Use RRTransformEqual in xf86RandR12CrtcSet Olivier Fourdan (9): glamor: Check for NULL pixmap in glamor_get_pixmap_texture() Xephyr: Check screen resources creation success glamor: glamor_set_destination_drawable() can fail glamor: Check glamor

Re: Pull request for server-1.19.branch fixes ?

nt. Xi: Test exact size of XIBarrierReleasePointer Michel Dänzer (5): xfree86/modes: Make colormap/gamma glue code work with RandR disabled os: Handle SIGABRT glamor: Store the actual EGL/GLX context pointer in lastGLContext glamor: Fix temporary pixmap coordinate offs

Re: Update PCI IDs for next xserver release

Hi Mark, > Please include the following commit in the next xserver release: > > abb031e731f5c159add1b3351de9c4bb121bf00a > dri2: Sync i965_pci_ids.h from Mesa. > > The ids are needed for us to test new systems with xorg. You actually need 2 commits on server-1.19-branch: abb031e73 dri2:

Re: Pull request for server-1.19.branch fixes ?

Hi Jason, > It doesn't look like my following fix didn't made it into your branch. > Overlooked, or didn't make the cut? > > https://cgit.freedesktop.org/~ofourdan/xserver/commit/?id=2fbf62b2fb3dcb29551251d09aa695715bb754f4 Yeap, that's just an overlook, sorry. Cheers, Olivier

Pull request for server-1.19.branch fixes ?

SendEvent request. Xi: Verify all events in ProcXSendExtensionEvent. Xi: Do not try to swap GenericEvent. Xi: Test exact size of XIBarrierReleasePointer Michel Dänzer (1): glamor: Fix temporary pixmap coordinate offsets Olivier Fourdan (9): glamor: Check for N

Re: [PATCH xserver 2/2 v3] glamor: Avoid overflow between box32 and box16 box

Hi all, Before I forget, would it be possible to consider these two patches for glamor: https://patchwork.freedesktop.org/series/27940/ This patch was successfully tested by Fabrice here (the reproducer is in bug #101894): https://lists.x.org/archives/xorg-devel/2017-July/054174.html And

Re: How to support mixed DPI in Xwayland?

Hi On 10 September 2017 at 22:25, Joseph Burt wrote: > > I'm now up to date on the relevant bug reports. Sorry for the spam. > > What about always running the X server at hardware resolution, > limiting the size of lodpi clients on the XWM side, and letting the > compositor

How to support mixed DPI in Xwayland?

Hi all, For quite some time now [1] we've been trying to figure out a way to have mixed DPI, both non-HiDPI capable X11 clients (e.g. xterm) and HiDPI aware X11 clients coexists on Xwayland. Typically, the compositor would scale the surface for xterm when on a HiDPI monitor, but would leave

[PATCH xserver 2/2] xwayland: apply output scale to monitor resolution

will be scaled up by the compositor). Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-output.c | 8 ++-- hw/xwayland/xwayland.h| 2 +- 2 files changed, 7 insertions(+), 3 deletions(-) diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c

[PATCH xserver 0/2] Add xdg-output support

in mutter would break mutter as the screen size would be wrong in gnome-shell/mutter with Xwayland. Cheers, Olivier Olivier Fourdan (2): xwayland: Add optional xdg-output support xwayland: apply output scale to monitor resolution configure.ac | 2 +- hw/xwayland/Makefile.am

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

). This was added in wayland-protocols 1.10. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- configure.ac | 2 +- hw/xwayland/Makefile.am | 9 +++- hw/xwayland/meson.build | 2 + hw/xwayland/xwayland-output.c | 119 ++--

[PATCH xserver] xwayland: No grab handler without protocol support

If the compositor has no support for the Xwayland keyboard grab protocol, there is no need to set-up our keyboard grab handler. Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 31 ++- 1 file changed, 22 insertions

[PATCH xserver] xwayland: Fix a segfault with pointer locking

stack in xwl_seat_maybe_lock_on_hidden_cursor() and return early if not the case to avoid the crash. Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=102474 Signed-off-by: Olivier Fourdan <ofour...@redhat.com> --- hw/xwayland/xwayland-input.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a

<    1   2   3   4   5   6   >