Re: [Linux-fbdev-devel] DirectFB without FBDev

Brian G. Rhodes wrote:

Denis Oliver Kropp wrote:

quoted

Brian G. Rhodes wrote:

quoted

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 

Yep, panning wasn't meant for buffer swapping initially :)

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.

You want to put something between fb driver and user space?

quoted

quoted

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.

No, it's just a FIFO between kernel and user space to set display offsets
within the frame buffer.

quoted

quoted

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?

I agree. It would be nice to have some cheap context switch from kernel to user
space, or some way to create a less privileged kernel thread with less overhead
during switching, but the ability to execute non-root user's code. I don't care
about the overhead from user to kernel (system call), but kernel to user (real time
thread for IRQs) should be optimized. Just dropping some privileges only sounds
simple in that case though :)

-- 
Best regards,
   Denis Oliver Kropp

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