Re: [directfb-users] DirectFB without FBDev

["Brian G. Rhodes" <bgr@acdstar.com>]

Denis Oliver Kropp wrote:
> 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.
>
>   

Seems like an end-run around supporting windows in framebuffer memory 
and using pan to jump back and forth.  This obviously was not the 
original intention of panning.   I have seen it used quite a bit for 
buffering and it seems like a pretty inelegant method for accessing the 
memory.  So you add a byte offset and a pitch so that you can pull out 
your next screen buffer.  Now you also need to add flags for the fb 
driver to tell the user-space implementation that it supports this 
functionality.  Pretty soon it's not a framebuffer driver.  Not that 
it's terribly atrocious what you suggest...  I didn't mean to come off 
as such.  I would just prefer that there is an intermediary interface to 
the fb driver which understands the hardware better and can manage these 
line-width writes better.

>> 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.
>
>   
No, it's not special with respect to the hardware.  It's special because 
you're turning your framebuffer into a fifo.
>> 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...
>
>   
I wouldn't want to signal userspace from an ISR to handle work.  All the 
unnecessary context switches just seem wasteful.  Or is there a better 
method now for waking up userspace from the kernel now?

-------------------------------------------------------------------------
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/