# Re: \[Linux-fbdev-devel\] DirectFB without FBDev - List: linux-fbdev - 2 messages, 2 authors - Page: https://ratatoskr.run/linux-fbdev/2008/05/13458207/t ## Re: \[Linux-fbdev-devel\] DirectFB without FBDev - From: Denis Oliver Kropp \ - Date: 2008-05-28 19:11:20 - Message: https://ratatoskr.run/linux-fbdev/2008/05/13458207.md ```text 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? >>> 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. >>> 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/ | "------------------------------------------" ``` ## Re: \[directfb-users\] DirectFB without FBDev - From: Brian G. Rhodes \ - Date: 2008-05-28 19:37:45 - Message: https://ratatoskr.run/linux-fbdev/2008/05/13458209.md ```text 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. ------------------------------------------------------------------------- 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/ ```