Updated requested feedback on video driver design

[Daniel Stone]

Hi Chase,

On Wed, Feb 24, 2010 at 12:19:57PM -0500, Alex Deucher wrote:
> On Wed, Feb 24, 2010 at 9:21 AM, Maupin, Chase <chase.maupin at ti.com> wrote:
> > In my last mail the link to the wiki page accidentally contained a period at the end which caused the link to fail.  Please see the updated link here
> >
> > http://wiki.davincidsp.com/index.php/Video_Processing_Subsystem_Driver_Design
> >
> > Again, any feedback you have would be greatly appreciated.
> 
> I would suggest using the drm KMS interface rather than fbdev for the
> display controllers.  It's much more flexible, especially if the hw
> supports multiple heads.

As Alex said, the fbdev API is incredibly deficient (even for cases less
complex than VPSS), and DRM/KMS is definitely the way to go.  Extending
the KMS API will allow you to do stuff like activate the HW composition
functionality much more sensibly than either hacking it through fbdev,
or mangling VPSS from userspace (!) leaving the kernel driver entirely
unaware of what just happened.

As concerns the document, most of it (regarding how to communicate with
the VPSS, etc) is low-level enough to only really concern the actual
driver author.  Since most of the document is skeletal though (there's a
lot of detail on how to use the syslink API, but then the entire
documentation for control is 'send commands to the video driver'?), it's
hard to say whether it's really useful or not.

One thing that strikes me is the 'frame' structure: to me, it looks like
this refers to a framebuffer/CRTC/etc (i.e. a particular configuration
of a section of a video device), whereas we tend to use it to refer to
one coherent image (and only the image itself, i.e. pixels only) either
from a capture device, or to be sent to the video device.  So if you're
using 'frame' in the former usage, you probably want to rename it to
avoid confusion; if you're using it to refer to pixels, most of the
information you've listed other than timestamp/field ID/etc seems
entirely superfluous.

Lastly, is there any way to map the current storage, analogous to
mmap()ing /dev/fbX on OMAP3 and below today, or is usage restricted to
queue()? If so, how are buffers created for submission to queue()?

Most of this isn't particularly X-specific though, so it would be nice
if there was a better discussion we could use -- perhaps linux-omap?

Cheers,
Daniel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.x.org/archives/xorg-devel/attachments/20100226/3191510a/attachment.pgp>