I suggest putting the XWayland API in a separate library.
There's still many things to fix (handling of the cursor for example),
and if we keep XWayland outside of the Xserver, I believe it's going
to be easier to update the API, and eventually break it when
it is needed.
I've looked closer at
On Sat, Oct 19, 2013 at 01:55:42PM +0200, Axel Davy wrote:
> > On Sat, Oct 19, 2013 at 10:49:04AM +0200, Axel Davy wrote:
> >> I've tried benchmarking AsyncSwap with the phoronix-test-suite,
> >> and I was surprised to see a regression with Openarena and Xonotic.
> >> According to dri devs, it is b
> On Sat, Oct 19, 2013 at 10:49:04AM +0200, Axel Davy wrote:
>> I've tried benchmarking AsyncSwap with the phoronix-test-suite,
>> and I was surprised to see a regression with Openarena and Xonotic.
>> According to dri devs, it is because, since I do an exchange, the
>> application
>> is fullscreen
On Sat, Oct 19, 2013 at 10:49:04AM +0200, Axel Davy wrote:
> I've tried benchmarking AsyncSwap with the phoronix-test-suite,
> and I was surprised to see a regression with Openarena and Xonotic.
> According to dri devs, it is because, since I do an exchange, the
> application
> is fullscreen and th
Given the recent discussion on the xorg-devel mailing list,
I think this new API shouldn't be merged within the X server.
The clear goal of the xorg team is toward dri3, and I was told
no patch enabling AsyncSwap for dri2 would be merged.
To implement the Present extension and composite efficie
The current XWayland API has no functionality to help the DDXs
implement ScheduleSwap. This new API proposal introduces functions
to manipulate the frame event, the release event, and to manipulate
the buffers that the Wayland compositor sees.
The first patch is not linked directly to XWayland,
