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? _______________________________________________ directfb-users mailing list directfb-users@directfb.org http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users
