Request for feedback for my GSoC project to improve Present support in Xwayland

[Roman Gilg]

Hi,

I'm working for my GSoC project on a better Present integration in
Xwayland. This should improve performance as well as minimize tearing. My
mentor is Daniel Stone and the starting point was my work on KWin and this
bug report: https://bugs.freedesktop.org/show_bug.cgi?id=99702.

I'm writing this mail in order to get some feedback from the X.Org
community regarding my current approach and the progress I've made so far.
You can find my main working branch at
https://github.com/subdiff/xserver/tree/presentInXwayland

I've tried to limit the changes to the Present code to a minimum. At the
moment it should be able to flip Glamor/GBM Pixmaps of Present supporting
clients to a Wayland surface for one full screen window without copies. The
restriction of only one window, which is full screen, is in line with what
is possible with the currently available functionality by the Present code
in the Xserver.

I have tried to queue events on msc timings, but it's not really
straightforward, since I think we need to read out some sort of Vblank
counter from the Wayland server instead of the kernel. The frame callback
is a candidate for that, but it needs at least in my KWin testing
environment always a previous buffer commit to signal back. I create
therefore dummy buffer commits, which then trigger the callback after every
frame if there are events in the queue. This seems to work most of the
times, but I've problems on window resizing. Apparently in these situations
it's difficult to pick the right Pixmap and the associated Wayland buffer
for the dummy commit. So for now I don't allow queuing events, which means
that Pixmap flips are applied always immediately. What's your opinion? Is
the construction with the frame callback as a msc counter and the dummy
commits a bad idea in general or do you maybe know the answer why the
window resizing is problematic in this context?

One of the basic ideas I had in the beginning was to create a separate
dummy RRCrtc for every Xwayland window. This was done under the assumption
that we don't only want to flip one window at a time. But since the Present
code doesn't support flipping multiple windows at all at the moment, we
could also use the xwl_outputs structs instead. That said, the current code
works and if there is nothing wrong with creating these RRCrtc, I would
leave it for now this way.

The code is only tested in a KWin session with a rootless Xwayland server.
I don't know if it could work in a non rootless Xwayland server as well,
maybe with some small adjustments. For now in this case it just falls back
to the old behavior without flips.

I have also worked on a second solution as a long term strategy. But it's
probably not in the scope of my GSoC project: The idea would be to remodel
the Present code in order to support Pixmap flips per CRTC, which would
enable the Xwayland DDX to flip every Wayland window individually. This
would be important if a compositor wants to support the scanout of client
buffers to overlay planes different to the primary planes of the CRTCs. In
my opinion it would also greatly increase the functionality in other DDX,
since being able to flip in a multi monitor setting a full screen window on
one CRTC alone is to my knowledge currently not possible when using only
one Screen struct in combination with RandR. But Daniel already warned me
that this rewrite would be very difficult to get right or maybe not doable
at all. The main reason for that is presumably that the Present code uses
in central parts the Screen Pixmap for its flipping. Also it would mean,
that current Present supporting DDX drivers need to be rewritten in some
parts.

This also leads to an explicit question in the end: Present changes the
Screen and Window Pixmaps via a TraverseTree operation. Why is this
necessary and why did using the same construction not work in my Xwayland
code? I change the Window Pixmaps currently directly in the Xwayland DDX
without traversing the tree:
https://github.com/subdiff/xserver/blob/presentInXwayland/hw/xwayland/xwayland-present.c#L224

Thanks in advance for your feedback.

Cheers
Roman
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.x.org/archives/xorg-devel/attachments/20170724/da60f932/attachment.html>