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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel


[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux