[PULL] Add VDPAU drivers to the server's DRI2 implementation

[Aaron Plattner]

On Sat, Oct 24, 2009 at 08:56:11AM -0700, Kristian Høgsberg wrote:
> On Fri, Oct 23, 2009 at 8:13 PM, Aaron Plattner <aplattner at nvidia.com> wrote:
> > Hi Keith,
> >
> > These changes add VDPAU driver name registration support to the X server.
> > I extended the driver type mechanism to allow a full DRI2InfoRec for VDPAU
> > drivers instead of just a name so that other drivers can return information
> > through the deviceName parameter.  libvdpau currently doesn't have a way of
> > passing the deviceName through to the backend driver, but we could add a
> > way to do that if it becomes necessary.
> 
> I don't think we need a new DRI2InfoRec for this.  Can we just add a
> field that's an array of driver names instead and a field that gives
> the length of that array?  Do you need a new device name for vdpau?

Well, what I really need is a way to get the driver name into libvdpau
without also specifying that my driver implements the DRI2 interface.  The
NVIDIA driver doesn't need to specify a device name at all: the VDPAU
backend library determines that through our private protocol.  I don't
really have a good sense of what a DRI2 VDPAU driver would look like
architecturally, but my assumption was that it would call DRI2Connect with
DRI2DriverDRI like any other DRI client would, after libvdpau used
DRI2DriverVDPAU to get the appropriate libvdpau_*.so backend name.  Would
it make sense to have a single DRI2Rec with one name, one device path, and
a bitmask of supported driver types?  E.g.

  static const DRI2DriverRec nvidiaVDPAUDriver = {
	.version = DRI2INFOREC_VERSION,
	.fd = -1,
	.driverName = "nvidia",
	.driverTypeMask = (1 << DRI2DriverVDPAU),
  };

Presumably a driver with a mask of (1 << DRI2DriverDRI) | (1 <<
DRI2DriverVDPAU) could use the same name for both kinds of drivers.

I could also just add completely new handling for DRI2DriverVDPAU such that
it only contains a name.  That's what I did originally, but figured
somebody might want the extra flexibility.  I'll implement whichever
interface you guys prefer.

-- Aaron