How would you do that? I can't see a way at all how ddx would reject a dri client.
By making the initialization fail, e.g.
Do you have some pointers how you'd do that? All code I see for initialization is on the dri side, except the generic stuff in dri.c. When it comes to initialization, there seems to be some black magic involved :-).
If I see that correctly, drm does neither reject clients based on features/version.
Maybe it doesn't yet, but it could.
Actually, it might be possible to use the DRM two-way handshake for this purpose? I'm not sure there's a driver specific handshake yet though, but adding that would probably be worthwhile anyway.
If there is some two-way handshake somewhere, I must have missed it.
There's none yet in the DDX, it would have to be added (if the one in the DRM doesn't suffice). It would probably be useful for other stuff like dynamic buffer offset updates (for Composite, pbuffers, ...) as well.
Actually, I can't see a two-way handshake in drm neither, any pointers?
DRI itself will refuse to load if the ddx major version doesn't match however, which is what Ian suggested to do (bump the ddx major version). Maybe that was indeed a good idea, even though it
means you'd have to update ddx if you got a new tiling-enabled dri (which isn't necessary otherwise). It would probably simplify
some things slightly.
For us maybe, but certainly not for users. Bumping the major version should be avoided whenever possible IMHO.
That's what I thought first too, I'm interested in other approaches...
Is there a good reason why tiling needs to be uniform over the whole rectangle? Because XAA expects it to be like that?
Yes.
(I basically think this is a design deficiency of XAA that it treats everything as a single big framebuffer.)
It arguably is, but that's the way it is.
Ok. For some reason, I can't get the version with pixmap cache untiled to work anyway correctly (clipping issues? can't change offset at any time?), so I guess I'll go back and try everything tiled again...
And also, for some reason "XaaNoOffscreenPixmaps" was needed to make it work that way.
Was the whole rectangle covered by a surface compensating for the tiling as well?
Yes.
Yes. It's possible I got that wrong though, I only quickly tried that, didn't work, thought there are more important issues to solve... But as
2) I was unable to make render work with the changed x coordinates trick, needed to support coordinates beyond 2048.
I think it should be possible that this works?
Maybe the calculation of the colour offset has to take the tiling into account?
That's eactly what I tried, but it didn't work.
So you aligned RB3D_COLOROFFSET to a tile, i.e. 2KB?
said, it's a moot point.
Ok, you've convinced me. I'd really wanted to make color tiling enabled by default in the end though, and this might just break some (existing) installations.It just seemed to be a little harsh to throw them out altogether - some people might like to use small (doublescan) physical resolutions for some OGL apps for speed reasons for instance, which would mean they'd need to restart the X server with tiling disabled just for that.
Are the rare cases where doublescan and interlaced modes are actually useful really worth the hassle of switching between tiling
and none though?
I'd vote for just throwing out doublescan and interlaced modes if tiling is enabled. Maybe put a note in the x log saying "turn off tiling for doublescan/interlaced modes"
Roland
------------------------------------------------------- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
