It seems to me a rather drastic solution to make the driver incompatible to the current drm just because of some new extensions (there are already extensions which only work if a certain drm version is present, but the driver works just fine if the drm is a bit older). And that blend_color is broken doesn't seem to be a serious enough problem that the driver would absolutely require a new drm version to run IMHO.As far as I can see though this would get very ugly, with lots of "if drm_version" code. And it might not be necessary (for instance if the BLENDCNTL register just "mirrors" the CBLENDCNTL, but leaves the values in ABLENDCNTL alone then it would be no problem at all). Maybe I'll try a bit harder to come up with a sample application for gl_ext_blend_func_separate next week, then it would be quite easy to figure out how the xBLENDCNTL registers interact.
I don't see why -- in userspace, just up the required drm minor number. In kernel space just define two new atoms (which happen to overlap the old one). What's the problem?
Roland
------------------------------------------------------- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps & Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
