Jesse Barnes wrote:
> On Thursday, September 27, 2007 3:35:22 pm Jesse Barnes wrote:
>> In one of my overzealous pipe/plane mapping patches, I renamed the pipes
>> field in drm_i915_flip_t to planes, since it's really dealing with
>> planes and so seemed to make sense.
>> However, drm_i915_flip_t has different compatibility requirements than
>> the i915 sarea private. The sarea private is duplicated in the Mesa
>> and DDX trees and used under a different name, so changes to it, as
>> long as they're binary compatible, are fine. drm_i915_flip_t, on the
>> other hand, is used under the same name by both the Mesa and DDX trees.
>> So if you build an old DDX or Mesa against a new DRM, they'll pick up
>> the new drm_i915_flip_t definition (since HAVE_I915_FLIP will be
>> defined) and promptly break. This patch reverts the DRM to the old
>> name and adds comments describing the actual field usage.
>> Sorry for the trouble.
> Oh, and for similar reasons, building a new Mesa or DDX against an old DRM
> will break, but keithp is making everything use the installed DRM headers all
> the time, so we can go back to the old drm_i915_flip_t field name then.
I've got a few issues using the git heads of Mesa, DRM and xf86-video-intel:
1. The Mesa 7.0.2 branch doesn't build with drm/master.
../common/dri_bufmgr.c: In function ‘driFenceBuffers’:
../common/dri_bufmgr.c:102: warning: passing argument 3 of
‘drmFenceBuffers’ makes integer from pointer without a cast
../common/dri_bufmgr.c:102: error: too few arguments to function
intel_buffers.c: In function ‘intelWindowMoved’:
intel_buffers.c:290: error: ‘drm_i915_flip_t’ has no member named ‘pipes’
intel_buffers.c:298: error: ‘drm_i915_flip_t’ has no member named ‘pipes’
intel_buffers.c: In function ‘intelPageFlip’:
intel_buffers.c:764: error: ‘drm_i915_flip_t’ has no member named ‘pipes’
Is this supposed to work? If so, please fix it.
If Mesa 7.0.2 is not intended to work with drm/master, what revision of
drm should work?
2. Mesa/master builds and runs but gears, for example, is limping along
at 83 fps (using >90% CPU). Can you test and see what you get?
Other demos are exhibiting rendering errors that I don't recall seeing
before (such as demos/gloss and demos/fogcoord).
Also, I had a total system lock-up when I exited gears at one point.
There's been a lot of changes lately and I don't know who's responsible
for the regressions but they need to be addressed.