Re: [directfb-users] DirectFB without FBDev

[Denis Oliver Kropp <dok@directfb.org>]

Brian G. Rhodes wrote:
>> Furthermore, the pan_display functionality could be enhanced to allow 
>> a kernel side queue
>> for frame accurate display of several buffers, e.g. video playback 
>> with five or more buffers
>> pre-rendered. A frame/sync counter and some new flags would be enough 
>> to be added for this.
>>   Ville Syrjala once did an extension like FBIO_FLIP or similar, maybe 
>> he can elaborate.
>>
>> I'm also seeing the need to have one pool of memory used by different 
>> frame buffer devices
>> or some other way to support multiple layers without statically 
>> partitioning memory that could
>> be managed more intelligently.
>>
>> And how about such capabilities like layer opacity, alpha ramps...?
>>
>> I know all this was not required to run the kernel based terminal 
>> emulation that the frame
>> buffer device has been invented for :)
>>
>>   
> 
> I don't think the solution to abstracting access to multiple hardware 
> planes which can be located in at dynamic memory addresses to be 
> implemented by adding complexity to the framebuffer driver.  It is 
> supposed to be just a dumb chunk of memory and storage for hardware 
> timings.

Adding the byte offset and pitch fits into this as well and would save
it from being removed from DirectFB.

> Considering video, and the amount of data which has to be shuffled 
> around for higher resolution/bitrate files it does not make sense to 
> require sending rendered frames off directly to a framebuffer device.  

I was not talking about copying any data back and forth, but just keep
a queue of start addresses assigned to future sync counters, being taken
care of in IRQs.

> It is too inefficient and in cases with hardware-assist (other than 
> coprocessors), likely unnecessary.  The answer probably isn't using 
> Video4Linux directly either.  Perhaps a DirectFB kernel component which 
> can standardize an interface and provide a better architecture than v4l2 
> does.  An application where, as mentioned above, you are using video 
> memory for multiple buffers as a implementation for queuing seems too 
> specialized to me to ever be done in a linuxfb driver.

It's not special regarding the hardware. Every driver with an interrupt
handler could support it.

> Has any thought been given to designing a DirectFB kernel-space 
> component which abstracts that access at the kernel level?  Seems to me 
> that it would make direct interaction from directfb with specialized 
> hardware much easier.

I don't think a new kernel graphics interface should be added, instead using
UIO to access MMIO, DMA and IRQs would be enough and implement most of the
graphics driver in user space. Downside is to loose the kernel console which
you usually don't need on an embedded device...

For acceleration and DMA/IRQ based programming, I still need to check if a
user space approach would be enough. So far I always handled IRQs in kernel
space for timing/performance reasons...

-- 
Best regards,
   Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/                 |
"------------------------------------------"

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/