Ian Romanick wrote:
> 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
If the client side 3D drivers are affected, you would also need to
factor old and new 3D drivers in to make 8 cases--but I certainly hope
the new DRM driver will support both old and new user space drivers
simultaneously [cases 1&3]. If so, adding the 3D driver would just be
redundant.
> 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.
Good idea. The DRM minor should be bumped anyway, and the new 2D driver
could check to see if the minor number was >= the version it needed for
video support.
> 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?
This is a possibility--but it might be easier to just have a new IOCTL
in the manner you or Vladimir have suggested below.
> 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"?
Either would work. Vladimir could reuse his versioning for other
changes--but keeping track of what changes worked with which version
would get confusing. Your suggestion is simple and might make
maintenance easier.
> 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.
Exactly. You could do this with Vladimir's IOCTL as well as long as the
DRM assumes a base level version if the IOCTL is not used that
identifies the old 2D driver.
> 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.
Ian, I like your suggestion--but we both have to keep in mind that
Vladimir is doing the leg work on this one. If his solution is
backwards compatible then I'd be inclined to go with what he and Kevin
Martin and Marc La France work out. They are the ones currently
maintaining the ATI driver code base.
> 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"? :)
I would imagine the video capture API has error handling. I would
recommend both logging the failure and returning an error code to the
client. The client usually has the best ability to gracefully handle
and report failures.
Regards,
Jens
-- /\
Jens Owen / \/\ _
[EMAIL PROTECTED] / \ \ \ Steamboat Springs, Colorado
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
