Denis Oliver Kropp wrote: > Brian G. Rhodes wrote: >> >> >> Denis Oliver Kropp wrote: >>> Brian G. Rhodes wrote: >>>> 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? > I would rather have an interface which marries the features of something like DirectFB with the functionality of kernel interfaces like linuxfb, v4l2 ..... rather than encumbering an interface like fbdev with too much intelligence. Or.. more specifically with interface additions which some hardware simply cannot support. >>>> 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. > I think that's splitting hairs but sure, a fifo between userspace and graphics memory implemented in the framebuffer driver. The next step will be padding this 'fifo' with headers which hold information like, PTS,DTS. >>>> 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 :) >
There are 4 cases for decode + display that I can think of. Software Software + Coprocessor Software + DSP Software + DSP with proprietary firmware interface The goal would be to make the first and last options work without either having to make sacrifices in performance while the application level can use a single interface. Maybe there's a nice way of gating this in userspace without dirtying up the kernel. I have yet to figure it out completely. Not without extending the ioctl interface of the fb driver with a bunch of crap specific to each platform. _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
