I've been watching this thread for awhile now, and I think it's time for me to inject my $0.02 worth. First, let me make sure that I've got things straight here.
Changes have been made to the 2D X driver to support video capture on Radeon cards. To support this change, the way that video memory (or is it register space?) is mapped must be changed. A portion of this initialization is done in the 2D X driver and the rest is done in the DRM portion (in the kernel). Both parts must agree on how memory is to be mapped, or the system will crash. Am I correct so far? Forgive my lack of understanding, but I thought that the DRM mapped everything in the places where non-kernel drivers told it to map. Isn't that the point of all the drmAddMap calls? Or do the drmAddMap calls just provide the physical-to-virtual mapping, and the mapping that is causing the problem here is some sort of physical-to-physical (using AGP hardware, perhaps) mapping? The crux of the problem is that the DRM portion is distributed with the kernel sources and the 2D X driver portion is distributed with the XFree86 sources. The odds that users will have matched versions are much, much worse then Vegas odds. Therefore, each part (DRM and 2D X driver) have to magically detect what the other part is capable of doing, and magically do the right thing. Here are the possible version combinations: 1. New DRM + new 2D X driver 2. Old DRM + new 2D X driver 3. New DRM + old 2D X driver 4. Old DRM + old 2D X driver Case 4 is trivial, and I won't consider it any further. In the remaining cases, each the DRM and the 2D X driver need some way to determine the capabilities of the other part so that they can know how to do the mapping. I believe that there is already some mechanism for determining the DRM version (drmGetVersion?). This makes cases 1 and 2 trivial. The new 2D X driver will determine the DRM version, and either setup the new mapping and support video capture, or log a message (or something similar) so that the user knows that video capture is unavailable. Here we have the potential for reduced functionality, but at least the system won't crash. The tricky case, and the case that Vladimir is stuck on, is number 3. How does the DRM know what the 2D X driver is going to do? Jens and Keith have suggested using a new set of IOCTLs. By this I assume that he meant having a new IOCTL number for an old IOCTL, and the new IOCTL would do the same thing. Simply by using the new entry point the DRM would know that the caller (i.e., the 2D X driver) is "new." Jens & Keith, is this what you meant? If so, which IOCTL(s) would need "new" versions? DRM_IOCTL_RADEON_CP_INIT? Vladimir has suggested an alternative. Adding a new IOCTL so that the 2D X driver would explicitly tell the DRM which version it is. I'm not sure that I like this so much as presents to possibility for a whole new can of worms in the future. Would it maybe better to add a new IOCTL to specifically say "Hey, use the new style memory layout"? So, when the 2D driver detects that the DRM is "new," it would use some form of new IOCTL. The DRM would then know that the 2D driver is also "new," and the DRM would perform the mapping accordingly. Otherwise, the 2D driver detects the old DRM version and disables video capture support, or the DRM gets the old IOCTL and performs the mapping the old way. Now, if all (or at least all the important parts) of the above is correct, is there any reason why we should not move forward with this solution? At first blush, there don't seem to be any horrible pitfalls, and I don't really see any other way that will keep us out of trouble with Linus and with our users. There is (at least) one remaining issue. In the case where a user has the new 2D part and wants to use video capture but doesn't have a new enough DRM, how do we effectively inform them? I don't think that just logging a message to the X log / syslog is good enough. Is there any other way? Could we do something perverted like "capture" a screen of text that says "You must upgrade your DRM to use video capture"? :) -- Tell that to the Marines! _______________________________________________ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
