Xwayland 24.1 branching and schedule

Hi all In preparation for the forthcoming Xwayland 24.1.0 release, I've now created the xwayland-24.1 branch: https://gitlab.freedesktop.org/xorg/xserver/-/tree/xwayland-24.1 And there's also a milestone that can be used to tag issues and merge requests targeting Xwayland 24.1.0:

Re: issues and merge requests

Hi, On Wed, Feb 7, 2024 at 11:47 AM Enrico Weigelt, metux IT consult < i...@metux.net> wrote: > On 07.02.24 00:59, Peter Hutterer wrote: > >> Closes: xorg/xserver#1631 > > > > It supports that too, but afaik the use of Fixes is more common in the > > xorg repo. In (some?) gnome OTOH repos Closes

Re: Patches to libXau

On Thu, Feb 1, 2024 at 4:09 PM Enrico Weigelt, metux IT consult < i...@metux.net> wrote: > have you checked whether it's already on gitlab.freedesktop.org ? > In that case just make a PR there ? > Indeed, it's there: https://gitlab.freedesktop.org/xorg/lib/libxau Cheers Olivier

Re: Hitting X limit in launching maximum number of vkcube instances

Hi Anuj, On Mon, Aug 14, 2023 at 8:27 PM Anuj Phogat wrote: > - I'm still getting the "_XSERVTransSocketUNIXAccept: accept() failed" > error > after launching ~ 256 instances of vkcube. I was able to find the root > cause of error after patching libxtrans based on Adam's suggestion: >

Re: Plan for an Xwayland 23.2 release

Hey Michel, On Fri, Jul 7, 2023 at 5:16 PM Michel Dänzer wrote: > > Sounds great to me. Hopefully we can merge > https://gitlab.freedesktop.org/xorg/xserver/-/merge_requests/1131 before > cutting the branch, assuming no major issues with it come up in the meantime. Yes, I have that one in

Re: Plan for an Xwayland 23.2 release

Hi all, On Thu, Jun 15, 2023 at 11:01 AM Olivier Fourdan wrote: > > Hi all, > > There are changes in Xwayland that I would like to see landed as part > of another Xwayland 23.2 release this year, as those could not make it > on time for 23.1, namely libEI support (

Plan for an Xwayland 23.2 release

Hi all, There are changes in Xwayland that I would like to see landed as part of another Xwayland 23.2 release this year, as those could not make it on time for 23.1, namely libEI support (now that libEI 1.0 was released), and possibly a few other changes: - Add EI support

Re: Hitting X limit in launching maximum number of vkcube instances

Hi On Thu, May 18, 2023 at 10:45 AM Anuj Phogat wrote: > > On Sat, May 6, 2023 at 9:04 AM Alan Coopersmith > wrote: > > > > On 5/5/23 16:07, Anuj Phogat wrote: > > > Thanks for the quick response Adam. I've seen this behavior across > > > multiple > > > graphics applications > > > and graphics

X.Org Security Advisory: CVE-2023-1393: X.Org Server Overlay Window Use-After-Free

X.Org Security Advisory: March 29, 2023 X.Org Server Overlay Window Use-After-Free == This issue can lead to local privileges elevation on systems where the X server is running privileged and remote code execution for ssh X forwarding sessions.

Re: Xwayland 23.1 schedule

Hi all, On Tue, Feb 14, 2023 at 10:45 AM Olivier Fourdan wrote: > > I'm preparing the release of Xwayland 23.1 and for that purpose filed > an issue in gitlab: > > https://gitlab.freedesktop.org/xorg/xserver/-/issues/1426 > > I have also prepared the branch

Xwayland 23.1 schedule

Hi all, I'm preparing the release of Xwayland 23.1 and for that purpose filed an issue in gitlab: https://gitlab.freedesktop.org/xorg/xserver/-/issues/1426 I have also prepared the branch and posted a draft MR (not to be merged!) here:

Re: Enabling gitlab CI across all the X.Org repos

Hi Alan On Wed, 3 Aug 2022 at 00:19, Alan Coopersmith wrote: > lib/libxcvt- I'm not quite sure how to add it here given > the unusual CI template setup for this repo > […] > It is just using ci-fairy, it's not that much different, just probably

Xwayland 22.1.1 tomorrow?

Hi all, It's been a month and half since Xwayland 22.1.0 was released. Since then, we landed a few but interesting fixes, so I plan to release Xwayland 22.1.1 tomorrow, unless someone disagrees. Cheers Olivier

Xwayland 22.1 schedule

Hi all, It's been a year since we released Xwayland standalone and the xwayland-21.1 branch. Some new (and nice!) features found their way in the master branch of the xserver since then and the time has come to consider a new xwayland-22.1 branch and release, similar to what Michel did a year or

Re: New libxcvt library

Hi Walter, On Fri, Apr 16, 2021 at 12:32 PM Walter Harms wrote: > i think it is a good idea. > Can you give a hint how big that lib is ? > Right now, it's extremely tiny, the lib is mostly one function taken from the xserver. https://gitlab.freedesktop.org/ofourdan/libxcvt Even when the idea

RFC: New libxcvt library

Hi all, Currently. the Xorg Xserver has its own implementation of the VESA CVT standard timing modelines generator in `hw/xfree86/modes/xf86cvt.c`. That code is placed in its own source file alone because it is also being used by the `cvt` utility. Because it's part of the Xorg DDX, Xwayland,

Re: Why matchbox window manager calls XRenderComposite from top to bottom?

Hi, It actually renders the screen in two passes. First pass from top to bottom, rendering only the opaque regions, while adding up each opaque region to a global clipping region. Second pass, from bottom to top, rendering only the translucent areas, clipping out the opaque regions that it

Re: PATCH: add -defaultRepeatDelay and -defaultRepeatInterval flags

Hi Michael, On Thu, 2 Apr 2020 at 14:35, Michael Stapelberg < michael+freedesk...@stapelberg.ch> wrote: > Friendly ping? :) > Best is to submit your patches as a merge request in gitlab, see: https://gitlab.freedesktop.org/xorg/xserver HTH Cheers Olivier

Re: MapNotify Event Is not received by the client after XMapWindow

Hi On Mon, Apr 29, 2019 at 9:41 AM Ikshwaku Chauhan wrote: > Hello All, > > > We are using Xorg version 1.14 and layermanger 1.1 with chromium browser > on NXP i.MX6 platform. > In one of our usecase chromium browser is crashing and we have found that, > this happens after XMapWindow api is

Re: Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)

Hi, On Thu, Jan 17, 2019 at 9:23 AM Pekka Paalanen wrote: > > On Wed, 16 Jan 2019 14:05:01 -0500 > Adam Jackson wrote: > > > On Wed, 2019-01-16 at 11:52 +0200, Pekka Paalanen wrote: > > > > > What I think we would need is a way to launch Xwayland, but ensure it > > > does not process the real

Re: Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)

On Wed, Jan 16, 2019 at 9:56 AM Olivier Fourdan wrote: > On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan wrote: > > > > Hi > > > > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen wrote: > > > > > > On Tue, 15 Jan 2019 23:21:05 +0100 > > >

Re: Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)

On Wed, Jan 16, 2019 at 9:55 AM Olivier Fourdan wrote: > > Hi > > On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen wrote: > > > > On Tue, 15 Jan 2019 23:21:05 +0100 > > Carlos Garnacho wrote: > > > > > If Xwayland gets to realize a window mean

Re: Xwayland on demand (Re: [PATCH xwayland 3/3] xwayland: Handle the case of windows being realized before redirection)

Hi On Wed, Jan 16, 2019 at 9:35 AM Pekka Paalanen wrote: > > On Tue, 15 Jan 2019 23:21:05 +0100 > Carlos Garnacho wrote: > > > If Xwayland gets to realize a window meant for composition before the > > compositor redirected windows (i.e. redirect mode is not RedirectDrawManual > > yet), the

Re: xmodmap really slow

On Mon, 3 Dec 2018 at 11:13, Alan Hourihane wrote: > No, didn't help I'm afraid. I'm not surprised, the patch probably helps but its contribution is negligible in regard to the huge delays being reported... I'd say, considering the delay, strace as indicated in my previous email would probably

Re: xmodmap really slow

On Fri, Nov 30, 2018 at 2:38 PM Alan Hourihane wrote: > [...] > Many thanks for following and providing a patch. > > Might take me till Monday, but running > > xmodmap -pke > /tmp/keydump > xmodmap /tmp/keydump > > Where the last command invokes multi-second delays should be easy to test.

Re: xmodmap really slow

On Fri, Nov 30, 2018 at 1:06 PM Olivier Fourdan wrote: > > On Fri, Nov 30, 2018 at 12:27 PM Alan Hourihane wrote: > > Running perf top while it's happening shows this > > > > 26.77% Xorg [.] ResourceClientBits > > 15.09% Xorg [.] G

[PATCH xserver] dix: cache ResourceClientBits() value

That saves running the same loop over and over. Signed-off-by: Olivier Fourdan --- dix/resource.c | 7 ++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/dix/resource.c b/dix/resource.c index b6ef99f10..e39df7773 100644 --- a/dix/resource.c +++ b/dix/resource.c @@ -620,7

Re: xmodmap really slow

On Fri, Nov 30, 2018 at 12:27 PM Alan Hourihane wrote: > Running perf top while it's happening shows this > > 26.77% Xorg [.] ResourceClientBits > 15.09% Xorg [.] GrabMatchesSecond > 12.62% Xorg [.] DetailSupersedesSecond.isra.1 > 12.55% Xorg

Re: [PATCH xserver 0/2] RFC: implement and use `present_event_abandon()`

Hi, On Mon, Oct 8, 2018 at 4:46 PM Olivier Fourdan wrote: > I reckon https://bugs.freedesktop.org/show_bug.cgi?id=108249 ("[xwayland] > Crash in Xpresent code on resume from suspend") is caused by the present > code using a RRCrtcPtr previously freed by Xwayland. > > R

[PATCH xserver 1/2] present: implement `present_event_abandon()`

for all windows for the given CRTC and abort those who match, so that we don't leave events behind referring to a `RRCtrcPtr` pointing to freed memory. Signed-off-by: Olivier Fourdan Bugzilla: https://bugs.freedesktop.org/108249 --- present/present_screen.c | 32 1

[PATCH xserver 0/2] RFC: implement and use `present_event_abandon()`

ll pretty much alien territory for me... Cheers, Olivier Olivier Fourdan (2): present: implement `present_event_abandon()` xwayland: abandon present events when removing CRTC hw/xwayland/xwayland-output.c | 3 ++- present/present_screen.c | 32 2 files ch

[PATCH xserver 2/2] xwayland: abandon present events when removing CRTC

we're about to destroy in `xwl_output_remove()`. Signed-off-by: Olivier Fourdan Bugzilla: https://bugs.freedesktop.org/108249 --- hw/xwayland/xwayland-output.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland-output.c b/hw/xwayland/xwayland-output.c index

[PATCH xserver] xwayland: keep `xwl_present_timer_callback()` private

`xwl_present_timer_callback()` is initially marked a private and later implemented as public. Let's keep that private, shall we. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-present.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hw/xwayland/xwayland-present.c

Re: [PATCH xserver 1/2] present: cancel flip on reparenting

idered: if there is already a different child > window doing flips on the new parent window the > reparented child window must be instructed to stop its flips. Whereas this would have been this patch 1/2 "present: cancel flip on reparenting" So do you mean we don't need this part and sho

[PATCH xserver 1/2] present: cancel flip on reparenting

cancel flip on the reparented window. Signed-off-by: Olivier Fourdan --- present/present_priv.h | 3 +++ present/present_scmd.c | 1 + present/present_screen.c | 16 present/present_wnmd.c | 17 + 4 files changed, 37 insertions(+) diff --git a/present

[PATCH xserver 2/2] xwayland: update Xwayland present window on reparent

window. Install new ReparentWindow hooks in Xwayland to handle those cases. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-present.c | 16 hw/xwayland/xwayland.c | 23 +++ hw/xwayland/xwayland.h | 2 ++ 3 files changed, 41 insertions

[PATCH xserver 0/2] RE: xwayland: Avoid assert failure in flips_stop()

ementing your suggestion, but I am not familiar with Present so this is a bit of a shot in the dark for me, also because that issue is quite difficult to reproduce. Those patches have been barely tested, expect dragons! Anyway, please let me know if that's what you had in mind... Cheers, Olivier Olivie

[PATCH xserver] xwayland: Use `double` for `xwl_tablet_tool`

So we do not lose subpixel precision in Xwayland. Suggested-by: Peter Hutterer Signed-off-by: Olivier Fourdan Tested-by: Jean-Loup Tastet Closes: https://gitlab.freedesktop.org/libinput/libinput/issues/138 --- MR: https://gitlab.freedesktop.org/xorg/xserver/merge_requests/21 hw/xwayland

[RFC PATCH xserver] xwayland: Avoid assert failure in flips_stop()

`FALSE` because `window->redirectDraw` was `RedirectDrawManual` and not the expected `RedirectDrawNone`. Signed-off-by: Olivier Fourdan --- See: https://lists.x.org/archives/xorg-devel/2018-September/057566.html hw/xwayland/xwayland-present.c | 3 +++ 1 file changed, 3 insertions(+) diff -

Re: [PATCH v2] present: fix freed pointer access

() retHi, On Fri, Sep 7, 2018 at 1:16 PM Olivier Fourdan wrote: > > > > On 04/09/2018 16:27, Roman Gilg wrote: > > > > > > Ok, I just got a failing assert in xwl_present_flips_stop with the patch > > > when opening a context menu in Steam. > > >

Re: [PATCH xserver 0/3] Xv: add NV12 support in glamor

mon/fourcc.h | 20 + > 7 files changed, 193 insertions(+), 28 deletions(-) > > -- > 2.7.4 > Nice! Tested with Xwayland using gstreamer, so: Tested-by: Olivier Fourdan Cheers, Olivier ___ xorg-devel@lists.x.org: X.Org development A

Re: [PATCH v2] present: fix freed pointer access

Hi, On Wed, Sep 5, 2018 at 1:13 PM Olivier Fourdan wrote: > Hi, > On Tue, Sep 4, 2018 at 6:28 PM Lionel Landwerlin > wrote: > > > > Oh well... > > I'm sure you'll be able to fix it faster than me :) > > > > - > > Lionel > > > > > [...

[PATCH xserver] glx: check for indirect context in CreateContextAttribsARB()

AttribsARB()` as well. Fixes: 99f0365b "Add a command line argument for disabling indirect GLX" Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107508 Signed-off-by: Olivier Fourdan --- glx/createcontext.c | 12 1 file changed, 12 insertions(+) diff --git a/glx/c

Re: [PATCH v2] present: fix freed pointer access

https://patchwork.freedesktop.org/patch/247271/ ** plus ** this patch below (just copied for testing purpose), does it fix th your crash? From 676597fcd6ee907f4d3f165dd0b5de746f7c8131 Mon Sep 17 00:00:00 2001 From: Olivier Fourdan Date: Wed, 5 Sep 2018 13:08:03 +0200 Subject: [PATCH xserver] x

Re: [PATCH xserver v3] xwayland: Remove xwl_present_window from privates on cleanup

Hi, On Wed, Sep 5, 2018 at 12:05 PM Lionel Landwerlin wrote: > > On 05/09/2018 09:49, Olivier Fourdan wrote: > > [...] > > This is because `xwl_present_cleanup()` frees the memory but does not > > remove it from the window's privates, and `xwl_present_abort_vblan

[PATCH xserver v3] xwayland: Remove xwl_present_window from privates on cleanup

`xwl_present_window` from window's privates on cleanup so that no other function can find and reuse that data once it's freed. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1616269 Signed-off-by: Olivier Fourdan --- v2: Remove leftovers from broken initial patch... v3: Rephrase non-sensical explanation

[PATCH xserver v2] xwayland: Remove xwl_present_window from privates on cleanup

`xwl_present_cleanup()` after `DestroyWindow()` so that `xwl_present_abort_vblank()` can still access valid memory before it's freed. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1616269 Signed-off-by: Olivier Fourdan --- v2: Remove leftovers from broken initial patch... hw/xwayland/xwayland-present.c

[PATCH xserver] xwayland: Remove xwl_present_window from privates on cleanup

`xwl_present_cleanup()` after `DestroyWindow()` so that `xwl_present_abort_vblank()` can still access valid memory before it's freed. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1616269 Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-present.c | 5 + hw/xwayland/xwayland.c | 10

Re: [PATCH xserver] xwayland: Clean-up present after destroying common bits

On Wed, Sep 5, 2018 at 9:48 AM Olivier Fourdan wrote: > > Right now, `xwl_destroy_window()` invokes `xwl_present_cleanup()` before > the common `DestroyWindow()`. > > But `DestroyWindow()` calls in `present_destroy_window()` which will > then end up in `xwl_present_abort_vblank

[PATCH xserver] xwayland: Clean-up present after destroying common bits

(main.c:276) by 0x75F611A: (below main) (libc-start.c:308) Move `xwl_present_cleanup()` after `DestroyWindow()` so that `xwl_present_abort_vblank()` can still access valid memory before it's freed. Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1616269 Signed-off-by: Olivier Fourdan

Re: Window scaling (aka owner sizes)

Hi Keith, On Mon, Aug 27, 2018 at 8:24 AM Keith Packard wrote: > > > I'm doing a bit of work to help support applications that want to run at > a small fixed size. The 'usual' way to make them visible on our modern > desktops is to flip video modes, but that means everything runs at low >

[PATCH v2 xserver] xwayland: Enable DRI3 for glamor

://bugs.freedesktop.org/show_bug.cgi?id=107287 Fixes: c8c276c956 ("glamor: Implement PixmapFromBuffers and BuffersFromPixmap") Signed-off-by: Olivier Fourdan Reviewed-by: Michel Dänzer --- v2: Fix "Fixes" vs. "Bugzilla" Add Michel's r-b hw/xwayland/xwayland-gla

[PATCH xserver] xwayland: Enable DRI3 for glamor

://bugs.freedesktop.org/show_bug.cgi?id=107287 Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor.c | 1 + 1 file changed, 1 insertion(+) diff --git a/hw/xwayland/xwayland-glamor.c b/hw/xwayland/xwayland-glamor.c index f17914344..7ea6def61 100644 --- a/hw/xwayland/xwayland-glamor.c +++ b/hw

Re: [PATCH xserver v2] xwayland: rotate logical size for RRMode

Hi, On Mon, Jul 16, 2018 at 10:47 AM Simon Ser wrote: > > On July 16, 2018 8:50 AM, Olivier Fourdan wrote: > > Hi, > > > > Thanks for your follow up on that! > > > > On Fri, Jul 13, 2018 at 9:51 PM Simon Ser wrote: > > > > > > Fr

Re: [PATCH xserver v2] xwayland: rotate logical size for RRMode

Hi, Thanks for your follow up on that! On Fri, Jul 13, 2018 at 9:51 PM Simon Ser wrote: > > From: emersion > > The logical size is the size of the output in the global compositor > space. The mode width/height should be scaled as in the logical > size, but shouldn't be transformed. Thus we

Re: [PATCH xserver] xwayland: rotate logical size for RRMode

Hi, On Wed, Jul 11, 2018 at 9:22 AM Simon Ser wrote: > > From: emersion > > The logical size is the size of the output in the global compositor > space. The mode width/height should be scaled as in the logical > size, but shouldn't be transformed. Thus we need to rotate back > the logical size

Re: [PATCH xserver] xwayland: don't use logical size for RRMode

Hi, On Tue, 10 Jul 2018 at 11:59, Simon Ser wrote: > Yes, that's intentional. When the physical size isn't available (e.g. when > using > projectors or virtual outputs) we just send zero. Do you think this is > harmful? According to the xrandr protocol definition:

Re: [PATCH xserver] xwayland: don't use logical size for RRMode

Hi, On Mon, 9 Jul 2018 at 09:17, Simon Ser wrote: > > The logical size is the size of the output in the global compositor > space. The mode width/height shouldn't be transformed and scaled. > > This fixes issues with pointer input on transformed outputs. > > Signed-Off-By: Simon Ser > --- >

Re: [PATCH xserver] modesetting: use drmmode_bo_import() for rotate_fb

On Fri, Jun 15, 2018 at 8:57 AM, Olivier Fourdan wrote: > drmmode_shadow_allocate() still uses drmModeAddFB() which may fail if > the format is not as expected, preventing from using a rotated output. > > Change it to use the new function drmmode_bo_import() which takes care

Re: [PATCH xserver 0/2] xwayland: couple of EGL backend API cleanup

Hi, On Fri, Jun 15, 2018 at 9:46 AM, Olivier Fourdan wrote: > Hi Emil, > > On Thu, Jun 14, 2018 at 7:38 PM, Emil Velikov > wrote: >> What's the blocker of pushing these - short on commit access, other? >> If the former, that should be addressed. You have done some ser

Re: [PATCH xserver 0/2] xwayland: couple of EGL backend API cleanup

Hi Emil, On Thu, Jun 14, 2018 at 7:38 PM, Emil Velikov wrote: > What's the blocker of pushing these - short on commit access, other? > If the former, that should be addressed. You have done some serious > work on Xwayland. I don't think I have commit access myself, never tried actually, never

[PATCH xserver] modesetting: use drmmode_bo_import() for rotate_fb

/show_bug.cgi?id=106715 Signed-off-by: Olivier Fourdan --- hw/xfree86/drivers/modesetting/drmmode_display.c | 7 ++- 1 file changed, 2 insertions(+), 5 deletions(-) diff --git a/hw/xfree86/drivers/modesetting/drmmode_display.c b/hw/xfree86/drivers/modesetting/drmmode_display.c index 859a21a9d

Re: [PATCH xserver] xwayland: add "tablet" into the tablet device names

On Mon, 11 Jun 2018 at 11:40, Peter Hutterer wrote: > On Mon, Jun 11, 2018 at 11:21:25AM +0200, Olivier Fourdan wrote: [...] > > > -pad->xdevice = add_device(pad->seat, "xwayland-pad", > > > +pad->xdevice = add_device(pad->seat, "xwayland

Re: [PATCH xserver] xwayland: add "tablet" into the tablet device names

ablet” and the device type, I'd rather have that consistent. >xwl_tablet_pad_proc); > pad->xdevice->public.devicePrivate = pad; > ActivateDevice(pad->xdevice, TRUE); > -- > 2.14.4 > > ___ > wayland

[PATCH xserver 0/2] xwayland: couple of EGL backend API cleanup

to review/test. Thanks! Olivier Olivier Fourdan (2): xwayland: simplify xwl_glamor_pixmap_get_wl_buffer() xwayland: mandatory EGL backend API hw/xwayland/xwayland-glamor-eglstream.c | 2 -- hw/xwayland/xwayland-glamor-gbm.c | 4 ++-- hw/xwayland/xwayland-glamor.c | 14

[PATCH xserver 2/2] xwayland: mandatory EGL backend API

The API init_wl_registry() and has_wl_interfaces() are marked as being optional, but both GBM And EGLStream backends implement them so there is point in keeping those optional. Suggested-by: Emil Velikov Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor.c | 8 +--- hw/xwayland

[PATCH xserver 1/2] xwayland: simplify xwl_glamor_pixmap_get_wl_buffer()

the xwl_glamor_pixmap_get_wl_buffer() and EGL backends API by removing the pixmap size, and use the drawable size instead. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 2 -- hw/xwayland/xwayland-glamor-gbm.c | 4 ++-- hw/xwayland/xwayland-glamor.c | 6 +- hw/xwayland

[PATCH xserver v3] xwayland: use pixmap size on present flip

continuous flickering. Use the actual pixmap's drawable size instead of the present box to create the buffer so that it's sized appropriately. Bugzilla: https://bugs.freedesktop.org/106841 Signed-off-by: Olivier Fourdan Reviewed-by: Michel Dänzer --- v2: Remove present_box, unused (thanks Michel

[PATCH xserver] xwayland: use pixmap size on present flip

continuous flickering. Use the actual pixmap's drawable size instead of the present box to create the buffer so that it's sized appropriately. Bugzilla: https://bugs.freedesktop.org/106841 Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-present.c | 4 ++-- 1 file changed, 2 insertions(+), 2

[PATCH xserver] xwayland: check pixmap size on present flip

continuous flickering. Check that the pixmap size and present box size match in xwl_present_flip() and return FALSE otherwise, so that we skip the pixmap with the wrong size. Bugzilla: https://bugs.freedesktop.org/106841 Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-present.c | 5 + 1

Re: [PATCH xserver] xawyland/glamor: Fix typo in xwl_glamor_pixmap_get_wl_buffer

Hi Vivek, On Fri, 8 Jun 2018 at 09:23, Vivek Das Mohapatra wrote: > > In the #else path of the #ifdef GBM_BO_WITH_MODIFIERS in > xwl_glamor_pixmap_get_wl_buffer there's a call to > gbm_go_get_stride: This should be gbm_bo_get_stride. > > Typo introduced in

Re: [PATCH xserver] present/wnmd: Preserve window pixmap's screen_x/y on flip

blank->pixmap->refcnt++; > dixDestroyPixmap(old_pixmap, old_pixmap->drawable.id); > -- > 2.17.1 > > ___ > xorg-devel@lists.x.org: X.Org development > Archives: http://lists.x.org/archives/xorg-devel > Info: https://lists.x

[PATCH xserver 09/10] xwayland: check for EGLStream backend explicitly

Now that we have separate backends for EGLStream and GBM, we can explicitly check for the EGLStream backend to disable present support in that case. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-present.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/hw

[PATCH xserver 10/10] xwayland: EGL_IMG_context_priority required by EGLStream

xwl_glamor_eglstream_init_egl() uses "EGL_IMG_context_priority" extension, make sure it's actually available before using it. Suggested-by: Emil Velikov Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 6 ++ 1 file changed, 6 insertions(+) diff

[PATCH xserver 06/10] xwayland: Add Wayland interfaces check

Introduces a new egl_backend function to let the EGL backend check for the presence of the required Wayland interfaces. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 28 ++--- hw/xwayland/xwayland-glamor-gbm.c | 14 + hw

[PATCH xserver 08/10] xwayland: refactor EGL backends for wayland registry

extensions available are all known to Xwayland. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 37 +- hw/xwayland/xwayland-glamor-gbm.c | 43 +++ hw/xwayland/xwayland-glamor.c | 94 - hw/xwayland/xwayland-present.c

[PATCH xserver 03/10] xwayland: GBM should fail w/out "GL_OES_EGL_image"

Surely, we should fail to init GBM backend if "GL_OES_EGL_image" is missing. This seems to have been lost with commit 1545e2dba ("xwayland: Decouple GBM from glamor"). Suggested-by: Emil Velikov Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-gbm.c | 4 +++

[PATCH xserver 07/10] xwayland: move EGL backend init to glamor

Move EGL backends initialization to its own function in xwayland-glamor.c Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor.c | 17 + hw/xwayland/xwayland.c| 16 ++-- hw/xwayland/xwayland.h| 2 ++ 3 files changed, 21 insertions(+), 14

[PATCH xserver 02/10] xwayland: swap "name" and "id" in init_wl_registry()

Both xwl_glamor_init_wl_registry() and the Wayland global registry handler use the interface id/name in that order, using name/id in the egl_backend vfunc makes things confusing and error prone. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 4 ++-- hw/xwayland

[PATCH xserver 05/10] xwayland: move egl_backend to its own struct

-by: Olivier Fourdan --- hw/xwayland/xwayland.h | 99 ++ 1 file changed, 51 insertions(+), 48 deletions(-) diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h index a32fcf6a5..6bbe72e46 100644 --- a/hw/xwayland/xwayland.h +++ b/hw/xwayland/xwayland.h

[PATCH xserver 01/10] xwayland: move glamor specific routines

ifdef XWL_HAS_GLAMOR" in xwayland.h Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 79 hw/xwayland/xwayland-glamor.c | 80 - hw/xwayland/xwayland.h | 24 3 files changed, 89 inserti

[PATCH xserver 04/10] xwayland: skip drm authentication with render node

If using a render node, we can skip DRM authentication. Suggested-by: Emil Velikov Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-gbm.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/hw/xwayland/xwayland-glamor-gbm.c b/hw/xwayland/xwayland-glamor-gbm.c index

[PATCH xserver 5/5] xwayland: make xwl_output_get_xdg_output() static

Make xwl_output_get_xdg_output() private, it doesn't need to be available elsewhere. Signed-off-by: Olivier Fourdan Reviewed-by: Lyude Paul Reviewed-by: Emil Velikov --- hw/xwayland/xwayland-output.c | 4 +++- hw/xwayland/xwayland.h| 1 - 2 files changed, 3 insertions(+), 2 deletions

[PATCH xserver 4/5] xwayland: do not disable glamor if EGLStream failed

they want to enable EGLStream on GPU which support it. Signed-off-by: Olivier Fourdan Reviewed-by: Lyude Paul Reviewed-by: Emil Velikov --- 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

[PATCH xserver 00/10] Re: Refactor egl_backends for wayland registry

Hi, This is a follow-up on https://patchwork.freedesktop.org/series/44095/ after Lyude and Emil reviews. Cheers, Olivier Olivier Fourdan (10): xwayland: move glamor specific routines xwayland: swap "name" and "id" in init_wl_registry() xwayland: GBM should fail w/o

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

(EE) 25: libc.so.6 (__libc_start_main) (EE) 26: Xwayland (_start) (EE) (EE) Fatal server error: (EE) Caught signal 6 (Aborted). Server aborting (EE) Aborted (core dumped) Signed-off-by: Olivier Fourdan Reviewed-by: Lyude Paul Reviewed-by: Emil Velikov --- hw/xwayland

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

rt() later in eglQueryDevicesEXT(). Signed-off-by: Olivier Fourdan Reviewed-by: Lyude Paul Reviewed-by: Emil Velikov --- 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 10064

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

ayland. Obviously, if Xwayland was built without EGLStream support, this has no effect. Signed-off-by: Olivier Fourdan Reviewed-by: Lyude Paul Reviewed-by: Emil Velikov --- hw/xwayland/xwayland.c | 10 -- 1 file changed, 4 insertions(+), 6 deletions(-) diff --git a/hw/xwayland/xwayland.c

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

e the most accurate description :) I rephrased the commit messages in 1/3 and in 5/5 as per your wording. I also fixed a few typos in the commit messages and added the R-b from both Lyude and yourself. Cheers, Olivier Olivier Fourdan (5): xwayland: allow "-eglstream" option xwayland:

Re: [PATCH xserver 5/5] xwayland: refactor egl_backends for wayland registry

Hi Emil, Many thanks for your detailed review! On Tue, Jun 5, 2018 at 12:37 PM, Emil Velikov wrote: > Hi Olivier, > > There's a handful of mostly trivial suggestions below. The idea itself seems > reasonable IMHO. One gripe is that we're 'leaking' twice as much as before. > > Namely: even if

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

Hi Emil, On 5 June 2018 at 12:41, Emil Velikov wrote: > [...] > >> > +#else > >> > +ErrorF("xwayland glamor: eglstream backend support not > >> > enabled\n"); > >> Something is really weird here: > >> > >> On one hand '-eglstream' is recognised and used (by potential user) on > >>

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

Hi On 4 June 2018 at 16:24, Emil Velikov wrote: > On 24 May 2018 at 15:10, Olivier Fourdan wrote: > > The command line option "-eglstream" used to enable EGLi stream support > > for NVidia GPU was made available only when Xwayland was built with EGL > > stream s

[PATCH xserver 2/5] xwayland: move egl_backend to its own struct

-by: Olivier Fourdan --- hw/xwayland/xwayland.h | 99 ++ 1 file changed, 51 insertions(+), 48 deletions(-) diff --git a/hw/xwayland/xwayland.h b/hw/xwayland/xwayland.h index 0d4afdf8a..0d6a4c246 100644 --- a/hw/xwayland/xwayland.h +++ b/hw/xwayland/xwayland.h

[PATCH xserver 4/5] xwayland: Move egl_backends init to glamor

Move EGL backends initialization and choice to its own function in xwayland-glamor.c Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor.c | 17 + hw/xwayland/xwayland.c| 16 ++-- hw/xwayland/xwayland.h| 2 ++ 3 files changed, 21

[PATCH xserver 0/5] Refactor egl_backends for wayland registry

work.freedesktop.org/series/43783/ https://patchwork.freedesktop.org/series/43931/ Which will be marked as such in patchwork. Cheers, Olivier Olivier Fourdan (5): xwayland: Move glamor specific routines xwayland: move egl_backend to its own struct xwayland: Add Wayland interfaces ch

[PATCH xserver 1/5] xwayland: Move glamor specific routines

ifdef XWL_HAS_GLAMOR" in xwayland.h Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 79 hw/xwayland/xwayland-glamor.c | 80 - hw/xwayland/xwayland.h | 24 3 files changed, 89 inserti

[PATCH xserver 5/5] xwayland: refactor egl_backends for wayland registry

extensions available are all known to Xwayland. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 27 ++ hw/xwayland/xwayland-glamor-gbm.c | 38 ++ hw/xwayland/xwayland-glamor.c | 69 ++--- hw/xwayland/xwayland-present.c

[PATCH xserver 3/5] xwayland: Add Wayland interfaces check

Introduces a new egl_backend function to let the EGL backend check for the presence of the required Wayland interfaces. Signed-off-by: Olivier Fourdan --- hw/xwayland/xwayland-glamor-eglstream.c | 20 hw/xwayland/xwayland-glamor-gbm.c | 14 ++ hw/xwayland

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

  1   2   3   4   5   6   >