The Compositor Modules are released, the modular C++ library for writing Wayland compositors

[Roman Gilg]

I'm happy to announce the first publicly available release of The
Compositor Modules, the modular C++ library to easily write a Wayland
compositor. The release is available on GitHub. [1]

You can read the full announcement with more details about the library
exclusively on Phoronix. [2]

The goal I once described at XDC 21 [3] has finally been reached by
that. There are still of course things to do, but the main library
structure is now in place. We can concentrate now on more feature
work. Check out the feature table in the main README to see what's
already there and what we plan on doing next.

If you're interested in using the library or contributing to it, let
me know either by email or join our Matrix room. [4]

[1] https://github.com/winft/como
[2] https://www.phoronix.com/review/the-compositor-modules-como
[3] https://youtu.be/lTp7al9FXFs?t=885
[4] https://matrix.to/#/#como:matrix.org

FDBuild Helps You Building Entire Wayland And X11 Graphic Stacks From Source

[Roman Gilg]

I recently created the first public release of FDBuild, a tool that I
have been using over the last years to build all the things I needed
to easily switch between hacking on Mesa, Wayland, XServer, etc.

I believe it offers a very convenient workflow for that because you
basically only need to remember a single command "fdbuild" and you are
able to rebuild many projects or only a single one.

You can get the tool easily with pip:
https://pypi.org/project/fdbuild/

And you can read more about it in this blog post:
https://subdiff.org/blog/2023/fdbuild-01-released

Re: [Mesa-dev] Gitlab Labels

[Roman Gilg]

On Tue, Aug 11, 2020 at 2:21 PM Mike Blumenkrantz
 wrote:
>
> Hi All,
>
> I was thinking it'd be nice to have labels in Mesa for difficulty in order to 
> help both newer and more experienced contributors choose issues/MRs which fit 
> their level of comfort and available time. This might look like:
>
> * easy
> * challenging
> * impossible

I think that's a good idea and as an example I created a system like
this in KWinFT [1]. There I'm using scoped labels which are to my
knowledge at the moment not yet available in the open source version
of GitLab, but it can also be done without this feature.

I chose also three levels and named them:
* beginner
* intermediate
* expert

In the hope that these terms are easy to understand and also to some
degree are motivating but sound neither condescending nor pretentious
(expert maybe but it fitted the other ones).

Colors are light blue, yellow, dark-orange and the label description
is always "difficulty to solve the issue is estimated to be {low,
middle, high}".

With good label descriptions I don't think there needs to be separate
documentation. One problem that might arise is that these labels only
are useful when people actually use them and you can forget easily
about them. I also always have to remind myself to add them to new
issues.

Cheers
Roman

[1] https://gitlab.com/groups/kwinft/-/issues

> Naturally we could then also create a task to document these labels, which I 
> assume we would tag as "impossible".
>
>
> Regards,
> Mike
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Plumbing explicit synchronization through the Linux ecosystem

[Roman Gilg]

On Wed, Mar 11, 2020 at 8:21 PM Jason Ekstrand  wrote:
>
> On Wed, Mar 11, 2020 at 12:31 PM Jason Ekstrand  wrote:
> >
> > All,
> >
> > Sorry for casting such a broad net with this one. I'm sure most people
> > who reply will get at least one mailing list rejection.  However, this
> > is an issue that affects a LOT of components and that's why it's
> > thorny to begin with.  Please pardon the length of this e-mail as
> > well; I promise there's a concrete point/proposal at the end.
> >
> >
> > Explicit synchronization is the future of graphics and media.  At
> > least, that seems to be the consensus among all the graphics people
> > I've talked to.  I had a chat with one of the lead Android graphics
> > engineers recently who told me that doing explicit sync from the start
> > was one of the best engineering decisions Android ever made.  It's
> > also the direction being taken by more modern APIs such as Vulkan.
> >
> >
> > ## What are implicit and explicit synchronization?
> >
> > For those that aren't familiar with this space, GPUs, media encoders,
> > etc. are massively parallel and synchronization of some form is
> > required to ensure that everything happens in the right order and
> > avoid data races.  Implicit synchronization is when bits of work (3D,
> > compute, video encode, etc.) are implicitly based on the absolute
> > CPU-time order in which API calls occur.  Explicit synchronization is
> > when the client (whatever that means in any given context) provides
> > the dependency graph explicitly via some sort of synchronization
> > primitives.  If you're still confused, consider the following
> > examples:
> >
> > With OpenGL and EGL, almost everything is implicit sync.  Say you have
> > two OpenGL contexts sharing an image where one writes to it and the
> > other textures from it.  The way the OpenGL spec works, the client has
> > to make the API calls to render to the image before (in CPU time) it
> > makes the API calls which texture from the image.  As long as it does
> > this (and maybe inserts a glFlush?), the driver will ensure that the
> > rendering completes before the texturing happens and you get correct
> > contents.
> >
> > Implicit synchronization can also happen across processes.  Wayland,
> > for instance, is currently built on implicit sync where the client
> > does their rendering and then does a hand-off (via wl_surface::commit)
> > to tell the compositor it's done at which point the compositor can now
> > texture from the surface.  The hand-off ensures that the client's
> > OpenGL API calls happen before the server's OpenGL API calls.
> >
> > A good example of explicit synchronization is the Vulkan API.  There,
> > a client (or multiple clients) can simultaneously build command
> > buffers in different threads where one of those command buffers
> > renders to an image and the other textures from it and then submit
> > both of them at the same time with instructions to the driver for
> > which order to execute them in.  The execution order is described via
> > the VkSemaphore primitive.  With the new VK_KHR_timeline_semaphore
> > extension, you can even submit the work which does the texturing
> > BEFORE the work which does the rendering and the driver will sort it
> > out.
> >
> > The #1 problem with implicit synchronization (which explicit solves)
> > is that it leads to a lot of over-synchronization both in client space
> > and in driver/device space.  The client has to synchronize a lot more
> > because it has to ensure that the API calls happen in a particular
> > order.  The driver/device have to synchronize a lot more because they
> > never know what is going to end up being a synchronization point as an
> > API call on another thread/process may occur at any time.  As we move
> > to more and more multi-threaded programming this synchronization (on
> > the client-side especially) becomes more and more painful.
> >
> >
> > ## Current status in Linux
> >
> > Implicit synchronization in Linux works via a the kernel's internal
> > dma_buf and dma_fence data structures.  A dma_fence is a tiny object
> > which represents the "done" status for some bit of work.  Typically,
> > dma_fences are created as a by-product of someone submitting some bit
> > of work (say, 3D rendering) to the kernel.  The dma_buf object has a
> > set of dma_fences on it representing shared (read) and exclusive
> > (write) access to the object.  When work is submitted which, for
> > instance renders to the dma_buf, it's queued waiting on all the fences
> > on the dma_buf and and a dma_fence is created representing the end of
> > said rendering work and it's installed as the dma_buf's exclusive
> > fence.  This way, the kernel can manage all its internal queues (3D
> > rendering, display, video encode, etc.) and know which things to
> > submit in what order.
> >
> > For the last few years, we've had sync_file in the kernel and it's
> > plumbed into some drivers.  A sync_file is just a wrapper around a
> 

Re: [Mesa-dev] [PATCH 1/2] loader_dri3: Wait for pending swaps to complete before drawable_fini.

[Roman Gilg]

On Sat, May 5, 2018 at 8:50 PM, Mario Kleiner
 wrote:
> Thanks. Can you see if you get any freezes in kwin_x11 by "violent
> alt-tabbing" with patch 1? I've seen two such freezes within 8 hours
> of normal use yesterday, each occuring when i alt-tabbed (normally)
> and the switcher side panel moved out from the left. Desktop was
> mostly blocked then, i assume it was kwin_x11 that got stuck. When
> VT-switching to the console and attaching gdb to kwin_x11 the
> backtrace showed it blocked in the loader_dri3_swapbuffer_barrier()
> from patch 1. I don't know if that was the cause of the freeze, or if
> something unrelated was going wrong and kwin just happens to block
> there when one VT switches away from the X-Server while kwin does its
> thing. Freezes happened both with compositing enabled and disabled.

Yes, I can confirm it happened to me as well now with patch 1.
Happened when holding Alt + Tab, but I had to try a few times. I
logged in directly with sddm and got the following backtrace without
VT switch by ssh session. So should be a clean one:

#0  0x7f4517e1074d in poll () at ../sysdeps/unix/syscall-template.S:84
#1  0x7f4516d32172 in poll (__timeout=-1, __nfds=1,
__fds=0x7ffed4e8ead0) at /usr/include/x86_64-linux-gnu/bits/poll2.h:46
#2  _xcb_conn_wait (c=c@entry=0xcc4be0, cond=cond@entry=0x19ef968,
vector=vector@entry=0x0, count=count@entry=0x0) at
/home/roman/dev/gfx/xcb/src/libxcb/src/xcb_conn.c:479
#3  0x7f4516d33e69 in xcb_wait_for_special_event (c=0xcc4be0,
se=0x19ef940) at /home/roman/dev/gfx/xcb/src/libxcb/src/xcb_in.c:795
#4  0x7f450d764d36 in dri3_wait_for_event_locked (draw=0x1a28288)
at ../../src/mesa/src/loader/loader_dri3_helper.c:457
#5  0x7f450d765568 in loader_dri3_wait_for_sbc
(draw=draw@entry=0x1a28288, target_sbc=47, target_sbc@entry=0,
ust=ust@entry=0x7ffed4e8eca0, msc=msc@entry=0x7ffed4e8eca8,
sbc=sbc@entry=0x7ffed4e8ecb0) at
../../src/mesa/src/loader/loader_dri3_helper.c:534
#6  0x7f450d76560b in loader_dri3_swapbuffer_barrier
(draw=0x1a28288) at
../../src/mesa/src/loader/loader_dri3_helper.c:1930
#7  loader_dri3_drawable_fini (draw=0x1a28288) at
../../src/mesa/src/loader/loader_dri3_helper.c:238
#8  0x7f450d75aaad in dri3_destroy_drawable (base=0x1a28250) at
../../src/mesa/src/glx/dri3_glx.c:349
#9  0x7f450d7537d2 in driReleaseDrawables (gc=gc@entry=0x1542920)
at ../../src/mesa/src/glx/dri_common.c:481
#10 0x7f450d75af0c in dri3_bind_context (context=0x1542920,
old=, draw=41946959, read=41946959) at
../../src/mesa/src/glx/dri3_glx.c:198
#11 0x7f450d746537 in MakeContextCurrent (dpy=0xcc3850,
draw=41946959, read=41946959, gc_user=0x1542920) at
../../src/mesa/src/glx/glxcurrent.c:213
#12 0x7f44fd3056fd in ?? () from
/usr/lib/x86_64-linux-gnu/qt5/plugins/xcbglintegrations/libqxcb-glx-integration.so
#13 0x7f45157d5229 in QOpenGLContext::makeCurrent(QSurface*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#14 0x7f451024ea5e in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#15 0x7f451024faa5 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#16 0x7f45157a5625 in QWindow::event(QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#17 0x7f45102c78c5 in QQuickWindow::event(QEvent*) () from
/usr/lib/x86_64-linux-gnu/libQt5Quick.so.5
#18 0x7f44d974565b in PlasmaQuick::Dialog::event(QEvent*) () from
/usr/lib/x86_64-linux-gnu/libKF5PlasmaQuick.so.5
#19 0x7f4515f40acc in QApplicationPrivate::notify_helper(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#20 0x7f4515f48417 in QApplication::notify(QObject*, QEvent*) ()
from /usr/lib/x86_64-linux-gnu/libQt5Widgets.so.5
#21 0x7f45152003c8 in QCoreApplication::notifyInternal2(QObject*,
QEvent*) () from /usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#22 0x7f451579a28d in
QGuiApplicationPrivate::processExposeEvent(QWindowSystemInterfacePrivate::ExposeEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#23 0x7f451579aebd in
QGuiApplicationPrivate::processWindowSystemEvent(QWindowSystemInterfacePrivate::WindowSystemEvent*)
() from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#24 0x7f45157748fb in
QWindowSystemInterface::sendWindowSystemEvents(QFlags)
() from /usr/lib/x86_64-linux-gnu/libQt5Gui.so.5
#25 0x7f44fec534b6 in ?? () from /usr/lib/x86_64-linux-gnu/libQt5XcbQpa.so.5
#26 0x7f45151fe64a in
QEventLoop::exec(QFlags) () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#27 0x7f4515207854 in QCoreApplication::exec() () from
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5
#28 0x7f45180e81f9 in kdemain () from
/usr/lib/x86_64-linux-gnu/libkdeinit5_kwin_x11.so
#29 0x7f4517d35830 in __libc_start_main (main=0x4006b0, argc=1,
argv=0x7ffed4e8f868, init=, fini=,
rtld_fini=, stack_end=0x7ffed4e8f858) at
../csu/libc-start.c:291
#30 0x004006e9 in _start ()

> So far, only using patch 2/2, i haven't seen any new freezes, but
> looking at the debug output i get a lot of these 

Re: [Mesa-dev] [PATCH 1/2] loader_dri3: Wait for pending swaps to complete before drawable_fini.

[Roman Gilg]

Without this patch plasmashell on Xserver/Mesa master freezes on me
when opening the launcher menu (Kickoff). With the patch haven't
experienced freezes yet.

Haven't tested the Steam client yet. Might be a different problem though.

Tested-by: Roman Gilg <subd...@gmail.com>

On Fri, May 4, 2018 at 3:45 PM, Mario Kleiner
<mario.kleiner...@gmail.com> wrote:
> Before destroying the loader_dri3_drawable, make sure all pending
> swaps for it have completed. This guides against the following scenario,
> which happens, e.g., with KDE Plasma-5's plasmashell (which uses
> QT-5's QtGui/QtQuick for rendering), when it repaints multiple
> UI elements, each represented by its own Window/GLXDrawable, using
> one common GLXContext for all GLXDrawable's:
>
> 1. glXMakeCurrent(dpy, drawable1, context);
> 2. glXXX render to drawable1
> 3. glXSwapBuffers(dpy, drawable1); #1
> 4. glXMakeCurrent(dpy, drawable2, context);
> 5. glXXX render to drawable2
> 6. glXSwapBuffers(dpy, drawable2);
> // While the swap #1 is still pending for drawable1:
> 7. glXMakeCurrent(dpy, drawable1, context);
> 8. glXXX render to drawable1
> 9. glXSwapBuffers(dpy, drawable1);
>
> Binding a different drawable2 to the same context via glXMakeCurrent
> will cause its previous drawable1 to be released (cfe. dri3_bind_context
> -> driReleaseDrawables), which in turn calls loader_dri3_drawable_fini().
> This unselects for Present notify event delivery on the associated
> X-Window and loses all dri3 related state. If drawable1 is selected for
> the context again [7], a new incarnation of loader_dri3_drawable is
> created in dri3_bind_context->driFetchDrawable->dri3_create_drawable->
> loader_dri3_drawable_init(), which again selects for Present notify
> event delivery for the underlying X-Window, but the new incarnation lost
> all state wrt. to previous rendering and swaps. The server now delivers
> PresentPixmapIdle and PresentPixmapComplete events from the completed
> previous swapbuffers call #1 [3] to the new loader_dri3_drawable, which
> doesn't expect those. One problem is that the new incarnation has a
> draw->send_sbc == 0, but now receives PresentPixmapComplete events with
> sbc's > 0, therefore updating draw->recv_sbc to > 0 in
> dri3_handle_present_event(). The draw->recv_sbc > draw_send_sbc is
> misinterpreted as sbc wraparound, triggers recv_sbc wraparound handling
> and ends up with a very large draw->recv_sbc. During the next swapbuffers
> call [9], the totally wrong recv_sbc is used for calculating the target_msc
> for the PresentPixmap request, leading to a target_msc billions of vblanks
> in the future, leading to a swap that never completes and thereby frozen UI
> and hang of the client.
>
> Make sure that a loader_dri3_drawable can only be destroyed after all
> its pending swaps have completed, to prevent misdelivery of PresentNotify
> events to the right X-Window, but the wrong incarnation of the associated
> loader_dri3_drawable.
>
> Signed-off-by: Mario Kleiner <mario.kleiner...@gmail.com>
> Cc: xorg-de...@lists.x.org
> Cc: dan...@fooishbar.org
> Cc: eero.t.tammi...@intel.com
> Cc: m...@fireburn.co.uk
> ---
>  src/loader/loader_dri3_helper.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/loader/loader_dri3_helper.c b/src/loader/loader_dri3_helper.c
> index 6bb11c4..7bd79af 100644
> --- a/src/loader/loader_dri3_helper.c
> +++ b/src/loader/loader_dri3_helper.c
> @@ -234,6 +234,9 @@ loader_dri3_drawable_fini(struct loader_dri3_drawable 
> *draw)
>  {
> int i;
>
> +   if (draw->special_event)
> +  loader_dri3_swapbuffer_barrier(draw);
> +
> draw->ext->core->destroyDrawable(draw->dri_drawable);
>
> for (i = 0; i < ARRAY_SIZE(draw->buffers); i++) {
> --
> 2.7.4
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] radeonsi: guard against indexbuf not being set

[Roman Gilg]

This is a RFC because I don't really know what I'm doing here. But we
have this problem with AMD and KWin already for quite a long time and
I hope it can be fixed now.

I followed the debug output and tried this guard. On my system this
fixed the issue with Alt+Tab crashing KWin. Still this might be not
the right solution to the problem.

According to git-blame 330d0607 was the last time this condition was touched.

On Mon, Mar 5, 2018 at 10:31 PM, Roman Gilg <subd...@gmail.com> wrote:
> Fixes crashes of clients when index_size != 0, but there was no indexbuf
> set in si_draw_vbo.
>
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103234
>
> Signed-off-by: Roman Gilg <subd...@gmail.com>
> ---
>  src/gallium/drivers/radeonsi/si_state_draw.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
> b/src/gallium/drivers/radeonsi/si_state_draw.c
> index ad470fd..e53da38 100644
> --- a/src/gallium/drivers/radeonsi/si_state_draw.c
> +++ b/src/gallium/drivers/radeonsi/si_state_draw.c
> @@ -680,7 +680,7 @@ static void si_emit_draw_packets(struct si_context *sctx,
> }
>
> /* draw packet */
> -   if (index_size) {
> +   if (index_size && indexbuf) {
> if (index_size != sctx->last_index_size) {
> unsigned index_type;
>
> --
> 2.7.4
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [RFC] radeonsi: guard against indexbuf not being set

[Roman Gilg]

Fixes crashes of clients when index_size != 0, but there was no indexbuf
set in si_draw_vbo.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103234

Signed-off-by: Roman Gilg <subd...@gmail.com>
---
 src/gallium/drivers/radeonsi/si_state_draw.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/drivers/radeonsi/si_state_draw.c 
b/src/gallium/drivers/radeonsi/si_state_draw.c
index ad470fd..e53da38 100644
--- a/src/gallium/drivers/radeonsi/si_state_draw.c
+++ b/src/gallium/drivers/radeonsi/si_state_draw.c
@@ -680,7 +680,7 @@ static void si_emit_draw_packets(struct si_context *sctx,
}
 
/* draw packet */
-   if (index_size) {
+   if (index_size && indexbuf) {
if (index_size != sctx->last_index_size) {
unsigned index_type;
 
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH] gallium: work around libtool relink issue for libdrm

[Roman Gilg]

This is similar to commit 90633079. libtool links first to system directories
instead of custom locations of libdrm on relinking. Since a more recent libdrm
version than the one provided by the system is often needed when compiling
mesa, make sure this works by putting libdrm in front.

See also: https://bugs.freedesktop.org/show_bug.cgi?id=100259

Signed-off-by: Roman Gilg <subd...@gmail.com>
---
 src/gallium/targets/dri/Makefile.am | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/src/gallium/targets/dri/Makefile.am 
b/src/gallium/targets/dri/Makefile.am
index 1d05d91..509faff 100644
--- a/src/gallium/targets/dri/Makefile.am
+++ b/src/gallium/targets/dri/Makefile.am
@@ -52,9 +52,9 @@ gallium_dri_la_LIBADD = \
$(top_builddir)/src/gallium/drivers/rbug/librbug.la \
$(top_builddir)/src/gallium/drivers/trace/libtrace.la \
$(top_builddir)/src/mapi/shared-glapi/libglapi.la \
+   $(LIBDRM_LIBS) \
$(SELINUX_LIBS) \
$(EXPAT_LIBS) \
-   $(LIBDRM_LIBS) \
$(GALLIUM_COMMON_LIB_DEPS)
 
 EXTRA_gallium_dri_la_DEPENDENCIES = \
-- 
2.7.4

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC][PATCH xserver] Multi-buffered flips on subsurfaces seg fault in Mesa

[Roman Gilg]

Sorry, somewhat part of my message got removed. It should begin with:

"This is a RFC on a follow-up patch to my recently posted patch series on
the
xorg-devel mailing list to enable per window flips of Present Pixmaps to
Wayland surfaces:
https://lists.freedesktop.org/archives/xorg-devel/2018-January/055674.html

The above patch series only allows flips..."

and so on.

On Mon, Jan 29, 2018 at 5:54 PM, Roman Gilg <subd...@gmail.com> wrote:

> The above patch series only allows flips on a child window with the same
> dimensions as its parent xwl_window. For flips on child windows (for
> example
> the video view port of a video player in windowed mode, see here:
> http://www.subdiff.de/assets/images/2017-07-28-a-new-beginning.jpg) I
> wanted
> to use Wayland subsurfaces as in the attached patch.
>
> The flipping itself works well on Weston and on KWin. But when shutting
> down
> KWin in the end I get always a segmentation fault in Mesa when cleaning up
> EGL
> via eglTerminate(EGLDisplay) through libepoxy.
>
> I pinpointed the seg fault to be a missing destroyImage function pointer
> here:
> https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/
> drivers/dri2/egl_dri2.c#n2685
>
> But I don't see currently what component is making the problems here or if
> the
> problem lies in my code.
>
>
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH xserver] xwayland: Flips on subsurfaces

[Roman Gilg]

Do flips for child windows via subsurfaces if the Wayland server
supports them.

Signed-off-by: Roman Gilg <subd...@gmail.com>
---
 hw/xwayland/xwayland-present.c | 57 +-
 hw/xwayland/xwayland.c |  6 -
 hw/xwayland/xwayland.h |  2 ++
 present/present_wnmd.c | 23 -
 4 files changed, 52 insertions(+), 36 deletions(-)

diff --git a/hw/xwayland/xwayland-present.c b/hw/xwayland/xwayland-present.c
index d08c39e..f68bf92 100644
--- a/hw/xwayland/xwayland-present.c
+++ b/hw/xwayland/xwayland-present.c
@@ -55,15 +55,22 @@ xwl_present_cleanup(WindowPtr window)
  * And therefore need to cleanup.
  */
 
+/* Clear frame callback */
 if (xwl_window->present_frame_callback) {
 wl_callback_destroy(xwl_window->present_frame_callback);
 xwl_window->present_frame_callback = NULL;
 }
 
+/* Clear surfaces */
+if (xwl_window->present_subsurface) {
+wl_subsurface_destroy(xwl_window->present_subsurface);
+wl_surface_destroy(xwl_window->present_surface);
+xwl_window->present_subsurface = NULL;
+}
+xwl_window->present_surface = NULL;
+
 /* Reset base data */
 xorg_list_del(_window->present_link);
-
-xwl_window->present_surface = NULL;
 xwl_window->present_window = NULL;
 
 TimerFree(xwl_window->present_frame_timer);
@@ -299,29 +306,31 @@ xwl_present_check_flip(RRCrtcPtr crtc,
 return FALSE;
 
 /*
- * We currently only allow flips of windows, that have the same
- * dimensions as their xwl_window parent window. For the case of
- * different sizes subsurfaces are presumably the way forward.
+ * Allow different sizes for the presenting window and its associated
+ * xwl_window only if the Wayland server supports subsurfaces.
  */
-if (!RegionEqual(_window->window->winSize, _window->winSize))
+if (!RegionEqual(_window->window->winSize, _window->winSize) &&
+!xwl_window->xwl_screen->subcompositor)
 return FALSE;
 
 return TRUE;
 }
 
-static void
+static Bool
 xwl_present_reset_present_window(struct xwl_window *xwl_window, WindowPtr 
present_window)
 {
 /* Do not reset if it is the same present_window. But this also means, that
  * we always switch to another child window, if it wants to present.
  */
 if (xwl_window->present_window == present_window)
-return;
+return FALSE;
 
 if (xwl_window->present_window)
 xwl_present_cleanup(xwl_window->present_window);
 xwl_window->present_window = present_window;
 xorg_list_add(_window->present_link, _present_windows);
+
+return TRUE;
 }
 
 static Bool
@@ -334,18 +343,37 @@ xwl_present_flip(WindowPtr present_window,
  RegionPtr damage)
 {
 struct xwl_window   *xwl_window = 
xwl_window_of_top(present_window);
-BoxPtr  present_box, damage_box;
+BoxPtr  win_box, present_box, damage_box;
+struct xwl_screen   *xwl_screen = xwl_window->xwl_screen;
 Boolbuffer_created;
 struct wl_buffer*buffer;
 struct xwl_present_event*event;
+struct wl_region*input_region;
 
+win_box = RegionExtents(_window->window->winSize);
 present_box = RegionExtents(_window->winSize);
 damage_box = RegionExtents(damage);
 
 /* Potentially reset the presenting window */
-xwl_present_reset_present_window(xwl_window, present_window);
-/* We can flip directly to the main surface (full screen window without 
clips) */
-xwl_window->present_surface = xwl_window->surface;
+if ( xwl_present_reset_present_window(xwl_window, present_window) ) {
+
+if (RegionEqual(_window->window->winSize, 
_window->winSize)) {
+/* We can flip directly to the main surface (full screen window 
without clips) */
+xwl_window->present_surface = xwl_window->surface;
+} else {
+xwl_window->present_surface =  
wl_compositor_create_surface(xwl_screen->compositor);
+wl_surface_set_user_data(xwl_window->present_surface, xwl_window);
+
+xwl_window->present_subsurface =
+wl_subcompositor_get_subsurface(xwl_screen->subcompositor, 
xwl_window->present_surface, xwl_window->surface);
+wl_subsurface_set_sync(xwl_window->present_subsurface);
+
+input_region = wl_compositor_create_region(xwl_screen->compositor);
+wl_surface_set_input_region(xwl_window->present_surface, 
input_region);
+wl_region_destroy(input_region);
+}
+
+}
 
 event = malloc(sizeof *event);
 if (!event) {
@@ -353,6 +381,11 @@ xwl_present_flip(WindowPtr present_window,
 return FALSE;
 }
 
+if (xwl_windo

[Mesa-dev] [RFC][PATCH xserver] Multi-buffered flips on subsurfaces seg fault in Mesa

[Roman Gilg]

The above patch series only allows flips on a child window with the same
dimensions as its parent xwl_window. For flips on child windows (for example
the video view port of a video player in windowed mode, see here:
http://www.subdiff.de/assets/images/2017-07-28-a-new-beginning.jpg) I wanted
to use Wayland subsurfaces as in the attached patch.

The flipping itself works well on Weston and on KWin. But when shutting down
KWin in the end I get always a segmentation fault in Mesa when cleaning up EGL
via eglTerminate(EGLDisplay) through libepoxy.

I pinpointed the seg fault to be a missing destroyImage function pointer here:
https://cgit.freedesktop.org/mesa/mesa/tree/src/egl/drivers/dri2/egl_dri2.c#n2685

But I don't see currently what component is making the problems here or if the
problem lies in my code.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev