Incompatible render changes

[Dave Airlie]

On Sun, Jul 20, 2008 at 5:25 AM, Soeren Sandmann <sandmann at daimi.au.dk> wrote:
> Keith Packard <keithp at keithp.com> writes:
>
>> On Sat, 2008-07-19 at 20:35 +0200, Soeren Sandmann wrote:
>>
>> > If not now, then when?
>>
>> Never seems like a fine option; they aren't hurting anything, are
>> they?
>
> Are you saying that API compatibility can never be broken at all
> whatsoever? Because that has not been the case so far. For example the
> mouse driver doesn't build at the moment.

I think we've learned from pciaccess and driver privates that breaking
the API due to being a bit lazy is very
bad.

All the drivers have compat layers for pciaccess and driver privates
now, however it would've been
much easier to start with the compat layer instead of doing it after the fact.

>
>> > If you can assume a new server, why not a new pixman?
>>
>> We can't assume a new server either; I try to package drivers that can
>> build back to Xorg 7.2 at least.
>
>>
>> Is there some utility in breaking compatibility here?
>
> There is utility in implementing a picture with a pixman_image_t
> internally to avoid creating a new one on each composite request that
> falls back to software.
>

So provide an interface in the X server to wrap the pixman calls under the
current API or even provide an simple file we can include in each driver
that wraps the current and old APIs so we can add a simple configure and that
file and it'll hide this stuff. The problem with having 3 X servers on
the fly, is driver
writers can't afford to keep 3 branches of their drivers going, and since nobody
liked my idea of pulling the drivers into the server, we get stuck
with doing compat API
support.

Dave.