[Intel-gfx] [PATCH] DRM planes
Daniel Vetter
daniel at ffwll.ch
Thu Nov 3 19:58:11 CET 2011
On Thu, Nov 03, 2011 at 05:47:43PM +0000, Alan Cox wrote:
> > In short decoding these fourcc values with all their implicit assumptions
> > about offset, strides and whatnotelse will be one giant switch mess. Not
> > my idea of a nice kernel interface. Also practically guaranteed to result
> > in slightly different behaviour in each driver.
>
> So you'd rather make each applicationa author get it wrong individually
> and uniquely. That is a bigger mess by far.
We're talking about gpus, there's no way an application will talk to them
than through some nice cozy abstraction layer like OpenGl, X, ... Even
Wayland has gbm to do the low-level kms scanout allocation.
> > In conclusion: Ditch the addfb2ioctl and just add a few more kms pixel
> > formats for the new packed yuv layouts that the snb+ sprite code needs.
>
> If you need a decoder for some hardware then fine, write one - share it
> with the v4l one and put it in a library drivers can call.
>
> However - user space is already working in fourcc, v4l has working fourcc
> and dumping the mess on the user isn't going to be a win.
The mess will be dumped onto userspace anyway, but it won't be dumped onto
the user - that one should use Xv or some fancy EGLImage extension.
-Daniel
--
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48
More information about the Intel-gfx
mailing list