On Wed, 2009-02-25 at 18:13 +0100, Michel Dänzer wrote: > On Wed, 2009-02-25 at 17:05 +0100, Matthias Hopf wrote: > > On Feb 24, 09 19:46:24 +0100, Michel Dänzer wrote: > > > On Tue, 2009-02-24 at 13:18 -0500, Chris Ball wrote: > > > > > EXA: Handle separate alpha maps properly in Composite fallback > > > > > > > > http://cgit.freedesktop.org/xorg/xserver/commit/?id=170cf1270dff38d3cce7f5ba5b940d1c0d70eff5 > > > > Driver maintainers: from this commit onwards, EXA requires you to pass > > > > in -DEXA_DRIVER_KNOWN_MAJOR=3, else it'll fail to build. If you use > > > > Prepare/FinishAccess, UploadToScratch or ExaOffscreenSwap*, you'll need > > > > to make other changes too. > > > > There used to be a time where API changes were supposed to be upwards > > and downwards compatible. I grieve for that time. > > So do I, in general... Unfortunately, this isn't always possible though. > > > Seriously, this change would have been easy to do in a less invasive > > manner by not nuking the hook, but just not using it any more. And by > > adding an additional hook for the new buffer types. > > You got that backwards (did anyone actually *look* at the change causing > this before complaining? :}: I removed the UploadToScratch hook because > I had to bump the major version, not the other way around. I had to bump > the major version (and add the #error) because the EXA_PREPARE_* indices > are passed to the driver Prepare/FinishAccess hooks, and some drivers > like radeon(hd) use them as indices into arrays. Without these measures, > the drivers would have continued to build and appeared to work, but > could have broken in subtle ways when overflowing the arrays. > > > > Enough ranting, radeonhd should be fixed now. > > Thanks, I hope you checked the Prepare/FinishAccess hooks for the above > (take a look at my radeon fix). >
What was wrong with defining a new flag that the driver passes back into EXA to say it supports the new bits? we have lots of flags, I don't see why adding a new one was so hard. Dave. > _______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
