Re: non-PCI driver name lookup

[Robert Swindells <rjs%fdy2.co.uk@localhost>]

Jared McNeill <jmcneill%invisible.ca@localhost> wrote:
>On Tue, 9 Jul 2019, Robert Swindells wrote:
>
>> I don't think that applications or higher level libraries should need to
>> work out whether they are connecting to a PCI graphics device or
>> something else and to call different libdrm functions to work with it.
>>
>> I'm testing this with multimedia/libva-utils and multimedia/libva,
>> running 'vainfo' should be able to get back 'sunxi' as the name of
>> the DRI2 device in use on the pinebook, then fail because there isn't
>> yet a libva driver for it.
>
>I think you're barking up the wrong tree. The hardware that sunxidrm 
>drives ("display engine") has no 2D accel, 3D accel, or video 
>encode/decode capabilities - it is a dumb framebuffer and video output 
>pipeline only. The encoder/decoder functions ("video engine") are an 
>entirely different, unrelated function.

I'm not barking up the wrong tree, it just isn't the tree that you think
it is.

The vainfo program is just an easy way to check whether we can connect
to the DRI2 extension, this is failing in MI code on the Pinebook.

I know that the video engine is separate, there is a reverse engineered
Linux driver for it which presents a libva driver to userland.

The missing link for the Pinebook may eventually be this:

https://github.com/i-rinat/libvdpau-va-gl

It is a vdpau driver that calls libva to decode videos then Mesa to
display them.

All this was partly prompted by a question about how to get HW video
decoding working on intel, I was comparing behaviour on different
machines to learn how the stack is supposed to work.