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

[Kristian Høgsberg]

2009/10/26 Aaron Plattner <aplattner at nvidia.com>:
> 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.

Do you have a DRI2 based VDPAU driver or are you just putting the
infrastructure in place for potential VDPAU drivers?  If you don't
have a driver on the way, maybe it makes more sense to add the DRI2
protocol for VDPAU when
we have an actual driver?

>  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.

The only thing DRI2 should do in this case is to give out a different
driver name for different driver types.  The thinking is that for
different driver types (GL, VDPAU, VAAPI, cairo-drm, etc), the
implementation may be split into differently named .so's and may even
group the chip support differently.  For example, for mesa, the intel
driver is either i915_dri.so or i965_dri.so, but cairo-drm may just
load cairo-drm-intel.so for all chipsets (just an example).  The drm
device file to use is the same in all cases though.

Right now, the DRI2 interface in the server doesn't support this,
since it only allows one driver name to be specified in the
DRI2InfoRec.  That's an oversight on my part.  But we can fix it by
adding an array of driver names to the struct and a length field.  If
the requested driver type passed in in DRI2Connect is outside the
array or the driver name entry is NULL, that driver type is not
supported and we can return BadValue.  Otherwise, we fill out the
return values and proceed as normal.

On the client side, this should be enough information to allow the
library to load the driver in question. The driver can use the
DRI2GetBuffers to get memory manager handles for the backing buffers
for the window and render directly into those.  Eventually it will use
DRI2CopyRegion to copy from a color buffer into the window.

cheers,
Kristian