Re: dma-buf/fbdev: one-to-many support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> The main issue is that fbdev has been designed with the implicit assumption 
> that an fbdev driver will always own the graphics memory it uses. All 
> components in the stack, from drivers to applications, have been designed 
> around that assumption.
> 
> We could of course fix this, revamp the fbdev API and turn it into a modern 
> graphics API, but I really wonder whether it would be worth it. DRM has been 
> getting quite a lot of attention lately, especially from embedded developers 
> and vendors, and the trend seems to me like the (Linux) world will gradually 
> move from fbdev to DRM.
> 
> Please feel free to disagree :-)

I would disagree on the "main issue" bit. All the graphics cards have
their own formats and cache management rules. Simply sharing a buffer
doesn't work - which is why all of the extra gloop will be needed.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux Input]     [Video for Linux]     [Gstreamer Embedded]     [Mplayer Users]     [Linux USB Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [Yosemite Backpacking]
  Powered by Linux