<div dir="ltr"><div>Hi,</div><div><br></div><div>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: <a href="https://bugs.freedesktop.org/show_bug.cgi?id=99702">https://bugs.freedesktop.org/show_bug.cgi?id=99702</a>.</div><div> </div><div>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 <a href="https://github.com/subdiff/xserver/tree/presentInXwayland">https://github.com/subdiff/xserver/tree/presentInXwayland</a></div><div><br></div><div>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.</div><div><br></div><div>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?</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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:</div><div><a href="https://github.com/subdiff/xserver/blob/presentInXwayland/hw/xwayland/xwayland-present.c#L224">https://github.com/subdiff/xserver/blob/presentInXwayland/hw/xwayland/xwayland-present.c#L224</a></div><div><br></div><div>Thanks in advance for your feedback.</div><div><br></div><div>Cheers</div><div>Roman</div></div>