Michel DÃnzer wrote:
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 :-).


E.g., the sequence of XF86DRI...() calls could be changed along the lines of: If the DDX DRI extension version determined by XF86DRIQueryVersion() indicates that it's supported, the client calls
something like XF86DRISetClientVersion() to indicate the
capabilities it has. XF86DRIGetDeviceInfo() could then fail if the
client's advertised capabilities don't allow direct rendering with
the DDX configuration. Of course, there's a lot of details to be
worked out around this idea, but I don't see anything that would
prevent it altogether, except maybe that it may not be possible while
preserving the interface between libGL and the 3D driver. :\
ah, a dri api change (would be the first since 2.5 years, btw), so we'd
bump the XF86DRI_MINOR_VERSION to 2 and just introduce that XF86DRISetClientVersion function (sounds like a good name to me).
Sounds good to me in theory, if not slightly complicated (the part about basing the decision on current ddx configuration sounds iffy). I have no clue though how you'd do that, how it travels through libGL and so on. I guess someone familiar with that interface stuff would need to implement it, it doesn't sound like something I could do...



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?


See drmSetInterfaceVersion() in xf86drm.c.
so, this is actually a handshake (I always thought that's just to figure
out what version the drm is)! If I see that correctly, when calling this
you can specify both a drm minor/major and actual driver major/minor
version. drm will then return an error if the major versions don't
match, or if the requested minor versions are larger than what the
drm/driver themself have. Additionally, if there is no error it will
also hopefully restrict drm features to those supported by the user
supplied drm minor/major values (the same is not done for the actual
driver, maybe that's not necessary).
Doesn't look like it could be used for what we need though.

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

Reply via email to