DirectFB without FBDev

DirectFB without FBDev

[Denis Oliver Kropp]

Hi,

after getting too depressed by the current state of the FBDev backend with the new
surface core I decided to drop FBDev support as it no longer fits into the architecture.

If you feel you like to fix the frame buffer device system module or better the frame
buffer device itself, you're welcome to help the FBDev backend to creep over the 1.2 hurdle...

One major bug at the moment is mode switching and pitch values being wrong. It's dumb to
return the pitch of the variable mode settings in the fixed settings structure anyhow, but
if you like to start with the above mentioned mission, that's where it could begin.

And while you're at it, please also add an ioctl to just simply set the display offset without
a virtual resolution and x/y offset values within the whole frame buffer...

I have no idea why the FBDev backend uses the wrong pitch (4096) after switching to RGB16 which
should have a pitch of 2048. One out of ten tries did work though. I remember it has been
working once I added several workarounds and hacks to keep the FBDev backend alive, but somehow
the code or core have changed, I don't know and I'm not in the mood of spending time on cruft
like VTs, FBDev etc...

Volunteers are welcome, urgently, I'm going to make a first release candidate of 1.2 tomorrow,
most likely after removing the fbdev system module.

-- 
Best regards,
   Denis Oliver Kropp

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

Re: DirectFB without FBDev

[Geert Uytterhoeven]

	Hi Denis,

On Wed, 28 May 2008, Denis Oliver Kropp wrote:
> One major bug at the moment is mode switching and pitch values being wrong. It's dumb to
> return the pitch of the variable mode settings in the fixed settings structure anyhow, but
> if you like to start with the above mentioned mission, that's where it could begin.

Do you care to tell us why this is dumb?

The pitch depends on the video mode and the hardware requirements,
that's why it's in struct fb_fix_screeninfo.

> And while you're at it, please also add an ioctl to just simply set the display offset without
> a virtual resolution and x/y offset values within the whole frame buffer...

Why do you need this? What's different compared to setting a virtual
resolution and a y offset (I assume you're talking about y only, as an x
offset without a virtual resolution doesn't make much sense).

Thanks!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

Re: DirectFB without FBDev

[Denis Oliver Kropp]

Geert Uytterhoeven wrote:
> 	Hi Denis,
> 
> On Wed, 28 May 2008, Denis Oliver Kropp wrote:
>> One major bug at the moment is mode switching and pitch values being wrong. It's dumb to
>> return the pitch of the variable mode settings in the fixed settings structure anyhow, but
>> if you like to start with the above mentioned mission, that's where it could begin.
> 
> Do you care to tell us why this is dumb?

Ok, the fixed information should not contain information that changes over time,
otherwise it is not fixed, at least that's my understanding of "fixed".

> The pitch depends on the video mode and the hardware requirements,
> that's why it's in struct fb_fix_screeninfo.

It would suffice to encode the pitch requirements independent from the video mode,
i.e. just put the pixel or byte alignment into the fixed structure.

>> And while you're at it, please also add an ioctl to just simply set the display offset without
>> a virtual resolution and x/y offset values within the whole frame buffer...
> 
> Why do you need this? What's different compared to setting a virtual
> resolution and a y offset (I assume you're talking about y only, as an x
> offset without a virtual resolution doesn't make much sense).

If you see the frame buffer as a big pool of memory in which you can allocate chunks
for being displayed or otherwise used by the hardware, it is a handicap if you need to
specify the offset of these buffers in non-linear mode after putting some 2D coordinate
system onto the 1D memory area.

I'd propose to allow user space to choose any byte offset and pitch as part of the variable
information that is compatible with the hardware. To achieve this the constrains should be
put into the fixed information.

fb_var_screeninfo
- remove/disable x_offset/y_offset
+ add byte_offset/byte_pitch

fb_fix_screeninfo
- remove variable pitch info
+ add byte/pixel alignment constrains for offset and pitch

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 :)

-- 
Best regards,
   Denis Oliver Kropp

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

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

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

[Brian G. Rhodes]

Denis Oliver Kropp wrote:
> Geert Uytterhoeven wrote:
>   
>> 	Hi Denis,
>>
>> On Wed, 28 May 2008, Denis Oliver Kropp wrote:
>>     
>>> One major bug at the moment is mode switching and pitch values being wrong. It's dumb to
>>> return the pitch of the variable mode settings in the fixed settings structure anyhow, but
>>> if you like to start with the above mentioned mission, that's where it could begin.
>>>       
>> Do you care to tell us why this is dumb?
>>     
>
> Ok, the fixed information should not contain information that changes over time,
> otherwise it is not fixed, at least that's my understanding of "fixed".
>
>   
>> The pitch depends on the video mode and the hardware requirements,
>> that's why it's in struct fb_fix_screeninfo.
>>     
>
> It would suffice to encode the pitch requirements independent from the video mode,
> i.e. just put the pixel or byte alignment into the fixed structure.
>
>   
>>> And while you're at it, please also add an ioctl to just simply set the display offset without
>>> a virtual resolution and x/y offset values within the whole frame buffer...
>>>       
>> Why do you need this? What's different compared to setting a virtual
>> resolution and a y offset (I assume you're talking about y only, as an x
>> offset without a virtual resolution doesn't make much sense).
>>     
>
> If you see the frame buffer as a big pool of memory in which you can allocate chunks
> for being displayed or otherwise used by the hardware, it is a handicap if you need to
> specify the offset of these buffers in non-linear mode after putting some 2D coordinate
> system onto the 1D memory area.
>
> I'd propose to allow user space to choose any byte offset and pitch as part of the variable
> information that is compatible with the hardware. To achieve this the constrains should be
> put into the fixed information.
>
> fb_var_screeninfo
> - remove/disable x_offset/y_offset
> + add byte_offset/byte_pitch
>
> fb_fix_screeninfo
> - remove variable pitch info
> + add byte/pixel alignment constrains for offset and pitch
>
> 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.

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

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.

Re: [directfb-users] DirectFB without FBDev

[Denis Oliver Kropp]

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.

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

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

-- 
Best regards,
   Denis Oliver Kropp

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

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

Re: [directfb-users] DirectFB without FBDev

[Alex Deucher]

On Wed, May 28, 2008 at 2:07 PM, Denis Oliver Kropp <dok@directfb.org> 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.
>
>> 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.
>
>> 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...

As you may or may not be aware, the drm is slowly getting modesetting
support including support for multiple crtcs and outputs and better
memory management.  Development is currently focusing on intel, but
AMD support will follow soon.  It even provides a legacy fbdev compat
layer.

http://cgit.freedesktop.org/mesa/drm/log/?h=modesetting-101

Alex

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

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

[Denis Oliver Kropp]

Alex Deucher wrote:
> As you may or may not be aware, the drm is slowly getting modesetting
> support including support for multiple crtcs and outputs and better
> memory management.  Development is currently focusing on intel, but
> AMD support will follow soon.  It even provides a legacy fbdev compat
> layer.
> 
> http://cgit.freedesktop.org/mesa/drm/log/?h=modesetting-101

It looks interesting and we should consider using libdrm in DirectFB,
but I could not find anything about display layers and it's already quite
big and kernel side drivers have this GPL issue etc...

-- 
Best regards,
   Denis Oliver Kropp

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

Re: [directfb-users] DirectFB without FBDev

[Alex Deucher]

On Wed, May 28, 2008 at 2:57 PM, Denis Oliver Kropp <dok@directfb.org> wrote:
> Alex Deucher wrote:
>>
>> As you may or may not be aware, the drm is slowly getting modesetting
>> support including support for multiple crtcs and outputs and better
>> memory management.  Development is currently focusing on intel, but
>> AMD support will follow soon.  It even provides a legacy fbdev compat
>> layer.
>>
>> http://cgit.freedesktop.org/mesa/drm/log/?h=modesetting-101
>
> It looks interesting and we should consider using libdrm in DirectFB,
> but I could not find anything about display layers and it's already quite
> big and kernel side drivers have this GPL issue etc...

In theory the code will be X11 licensed since it's coming from Xorg
and shared with BSD, but I guess it's kind of a grey area.

Alex

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

Re: [directfb-users] DirectFB without FBDev

[Brian G. Rhodes]

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/

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

[Denis Oliver Kropp]

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

[Brian G. Rhodes]

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/

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

[Sven Luther]

On Wed, May 28, 2008 at 08:07:10PM +0200, Denis Oliver Kropp wrote:
> Brian G. Rhodes wrote:
> 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...

Euh, well, i think the X / OpenGL approach showed us that to do DMA/IRQ,
you need a kernel module, and what X/OpenGL is the DRI thingy.

Would it make sense for directfb to re-use this selfsame infrasturcture,
which already exists in the kernel, and is used by X, so kind of
guaranteed to be available for many graphic cards ? 

But maybe it is too complex or something ? 

Friendly,

Sven Luther

Re: [directfb-dev] [directfb-users] DirectFB without FBDev

[Denis Oliver Kropp]

Sven Luther wrote:
> On Wed, May 28, 2008 at 08:07:10PM +0200, Denis Oliver Kropp wrote:
>> Brian G. Rhodes wrote:
>> 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...
> 
> Euh, well, i think the X / OpenGL approach showed us that to do DMA/IRQ,
> you need a kernel module, and what X/OpenGL is the DRI thingy.

In some cases performance might be sufficient if IRQs are just routed to user
space and handled in a real time thread. You can program the DMA engine from
user space, it's just the IRQ that's only arriving in kernel space.

> Would it make sense for directfb to re-use this selfsame infrasturcture,
> which already exists in the kernel, and is used by X, so kind of
> guaranteed to be available for many graphic cards ? 

If there are drivers within this framework that we could use it makes sense,
but for writing support for a new chip one has to consider the overhead of
using a framework vs benefits. Overhead could be in time to develop and/or at
runtime. Benefits could be safety by relying on proven core code, but also saving
time to develop by having to write less code.

> But maybe it is too complex or something ? 

It depends on what you need in kernel space. Have a look at the SH7722 kernel
module. I'm not sure if the benefits of DRI would be that big to compensate for
the overhead or limitations. E.g. this driver manages a self running DMA queue,
where in the ideal case you never have to do any system call, but just append data
to the DMA buffer from user space.

http://git.directfb.org/?p=core/DirectFB.git;a=blob;f=gfxdrivers/sh7722/kernel-module/sh7722gfx.c

This driver handles different interrupt sources, provides DMA for the accelerator
as mentioned above and implements a minor portion of JPEG encoding and decoding with
the rest done in user space.

-- 
Best regards,
   Denis Oliver Kropp

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

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

Re: [directfb-dev] [directfb-users] DirectFB without FBDev

[Sven Luther]

On Sat, May 31, 2008 at 08:08:54AM +0200, Denis Oliver Kropp wrote:

<skipped>

> It depends on what you need in kernel space. Have a look at the SH7722 
> kernel
> module. I'm not sure if the benefits of DRI would be that big to compensate 
> for
> the overhead or limitations. E.g. this driver manages a self running DMA 
> queue,
> where in the ideal case you never have to do any system call, but just 
> append data
> to the DMA buffer from user space.
> 
> http://git.directfb.org/?p=core/DirectFB.git;a=blob;f=gfxdrivers/sh7722/kernel-module/sh7722gfx.c
> 
> This driver handles different interrupt sources, provides DMA for the 
> accelerator
> as mentioned above and implements a minor portion of JPEG encoding and 
> decoding with
> the rest done in user space.

Yes, but given that the kernel already has 2 "graphical" subsystems, fbdev
an drm, the reticence of Linus to merge in the fbdev back then, and the
failure of the ggi/kgi project, i wonder if it makes sense to try to add
yet another system.

In my opinion, what would make sense would be to disucss with the fbdev
and drm/xorg folk, as well as the vendors out there, to obtain a single
unified "graphical" driver, on which fbdev and xorg/drm functionality
can be built, and which allows us to take advantage of the various
functionality of the graphic chips, and which is designed, not only for
high end desktop/workstation graphic cards, but also for embedded
chipsets.

Friendly,

Sven Luther

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

Re: [directfb-dev] [directfb-users] DirectFB without FBDev

[Denis Oliver Kropp]

Sven Luther wrote:
> On Sat, May 31, 2008 at 08:08:54AM +0200, Denis Oliver Kropp wrote:
> 
> <skipped>
> 
>> It depends on what you need in kernel space. Have a look at the SH7722 
>> kernel
>> module. I'm not sure if the benefits of DRI would be that big to compensate 
>> for
>> the overhead or limitations. E.g. this driver manages a self running DMA 
>> queue,
>> where in the ideal case you never have to do any system call, but just 
>> append data
>> to the DMA buffer from user space.
>>
>> http://git.directfb.org/?p=core/DirectFB.git;a=blob;f=gfxdrivers/sh7722/kernel-module/sh7722gfx.c
>>
>> This driver handles different interrupt sources, provides DMA for the 
>> accelerator
>> as mentioned above and implements a minor portion of JPEG encoding and 
>> decoding with
>> the rest done in user space.
> 
> Yes, but given that the kernel already has 2 "graphical" subsystems, fbdev
> an drm, the reticence of Linus to merge in the fbdev back then, and the
> failure of the ggi/kgi project, i wonder if it makes sense to try to add
> yet another system.

I wouldn't try to add another system either, but write small, specialized and
optimized kernel modules suited best for the way the hardware works to take as
most advantage as possible. The example shows that 600 lines of hardware plus
200 lines of Linux code suffice in the SH7722 case.

> In my opinion, what would make sense would be to disucss with the fbdev
> and drm/xorg folk, as well as the vendors out there, to obtain a single
> unified "graphical" driver, on which fbdev and xorg/drm functionality
> can be built, and which allows us to take advantage of the various
> functionality of the graphic chips, and which is designed, not only for
> high end desktop/workstation graphic cards, but also for embedded
> chipsets.

A single unified solution would be nice, but it's always a trade off. For
embedded chipsets there's a unified solution in user space as well as for
desktops, while the former can be used for desktops with limitations and
the latter can be used for embedded with overhead.

-- 
Best regards,
   Denis Oliver Kropp

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

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

Re: [directfb-dev] [directfb-users] DirectFB without FBDev

[Sven Luther]

On Sat, May 31, 2008 at 08:29:52AM +0200, Denis Oliver Kropp wrote:
> Sven Luther wrote:
> >Yes, but given that the kernel already has 2 "graphical" subsystems, fbdev
> >an drm, the reticence of Linus to merge in the fbdev back then, and the
> >failure of the ggi/kgi project, i wonder if it makes sense to try to add
> >yet another system.
> 
> I wouldn't try to add another system either, but write small, specialized 
> and
> optimized kernel modules suited best for the way the hardware works to take 
> as
> most advantage as possible. The example shows that 600 lines of hardware 
> plus
> 200 lines of Linux code suffice in the SH7722 case.

The risk is ending with a bunch of different such kernel modules without
any unified kernel-userland interface, and it will end up in a mess,
just like the different powerpc embedded board support ended up with a
huge in-kernel mess which is beign fixed right now.

> >In my opinion, what would make sense would be to disucss with the fbdev
> >and drm/xorg folk, as well as the vendors out there, to obtain a single
> >unified "graphical" driver, on which fbdev and xorg/drm functionality
> >can be built, and which allows us to take advantage of the various
> >functionality of the graphic chips, and which is designed, not only for
> >high end desktop/workstation graphic cards, but also for embedded
> >chipsets.
> 
> A single unified solution would be nice, but it's always a trade off. For

Why should there be a tradeoff ? The kernel space part should expose the
functionality of the hardware, and there is not thousand of ways to do
this, and the needs of all the userland users of this are pretty much
the same, or at least similar.

> embedded chipsets there's a unified solution in user space as well as for
> desktops, while the former can be used for desktops with limitations and
> the latter can be used for embedded with overhead.
> 
User space is easy, its the kernel space which is the problem.

Friendly,

Sven Luther

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

Re: [directfb-users] DirectFB without FBDev

[George Tsalikis]

I am sorry to intrude in your discussion, since i am not an expert but i 
would like to point:
Shouldn't you consider now to become as cross-platform kernel-wise as 
possible?

Re: [directfb-dev] [directfb-users] DirectFB without FBDev

[Denis Oliver Kropp]

George Tsalikis wrote:
> I am sorry to intrude in your discussion, since i am not an expert but i 
> would like to point:
> Shouldn't you consider now to become as cross-platform kernel-wise as 
> possible?

DRI is somewhat cross platform running on Linux and BSD.

DirectFB is cross platform as it's a user space library and can be ported
to any other OS with a bit of POSIX support. There's only a kernel module
(usually small) for certain drivers or in case you want to run multiple
processes in one session. But if the OS does not have separate processes,
it's not required anyhow, as each application is a thread there.

What do you mean by kernel-wise? Like DRI with shared kernel code between
Linux and BSD or like DirectFB with shared user space code portable over
different kernels?

-- 
Best regards,
   Denis Oliver Kropp

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

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

Re: [directfb-dev] DirectFB without FBDev

[George Tsalikis]

O/H Denis Oliver Kropp έγραψε:
> George Tsalikis wrote:
>> I am sorry to intrude in your discussion, since i am not an expert but i 
>> would like to point:
>> Shouldn't you consider now to become as cross-platform kernel-wise as 
>> possible?
> 
> DRI is somewhat cross platform running on Linux and BSD.
> 
I thought it was Linux and among the BSDs only FreeBSD.

> DirectFB is cross platform as it's a user space library and can be ported
> to any other OS with a bit of POSIX support. There's only a kernel module
> (usually small) for certain drivers or in case you want to run multiple
> processes in one session. But if the OS does not have separate processes,
> it's not required anyhow, as each application is a thread there.
> 
Speaking about Fusion?

> What do you mean by kernel-wise? Like DRI with shared kernel code between
> Linux and BSD or like DirectFB with shared user space code portable over
> different kernels?
> 
I like DirectFB like how it is now. Even though the DRM kernel component 
would save you some coding it would bind DirectFB to a specific team's 
work creating a grade of dependency and limit it to specific kernels 
which is not aiding diversity and evolution. Plus the overhead, plus the 
fact this will get DirectFB one step closer to X which is imo 
"politicaly incorrect".

Would it be hard for you to pick the old FBDev code and adopt it under 
DirectFB? We dont need our own kernel level infrastructure in order to 
go on without DRI.


_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users

Re: [directfb-dev] DirectFB without FBDev

[Denis Oliver Kropp]

George Tsalikis wrote:
> O/H Denis Oliver Kropp έγραψε:
>> George Tsalikis wrote:
>>> I am sorry to intrude in your discussion, since i am not an expert but i 
>>> would like to point:
>>> Shouldn't you consider now to become as cross-platform kernel-wise as 
>>> possible?
>> DRI is somewhat cross platform running on Linux and BSD.
>>
> I thought it was Linux and among the BSDs only FreeBSD.

You probably better know than I :)

>> DirectFB is cross platform as it's a user space library and can be ported
>> to any other OS with a bit of POSIX support. There's only a kernel module
>> (usually small) for certain drivers or in case you want to run multiple
>> processes in one session. But if the OS does not have separate processes,
>> it's not required anyhow, as each application is a thread there.
>>
> Speaking about Fusion?

Regarding multiple processes, yes. You could also use the SysV user space
multi app core, but it never fully worked for me and I'm not sure about
the performance.

>> What do you mean by kernel-wise? Like DRI with shared kernel code between
>> Linux and BSD or like DirectFB with shared user space code portable over
>> different kernels?
>>
> I like DirectFB like how it is now. Even though the DRM kernel component 
> would save you some coding it would bind DirectFB to a specific team's 
> work creating a grade of dependency and limit it to specific kernels 
> which is not aiding diversity and evolution. Plus the overhead, plus the 
> fact this will get DirectFB one step closer to X which is imo 
> "politicaly incorrect".

DirectFB fortunately is very modular and using DRM would just mean we add
another system module next to FBDev, DevMem, X11, SDL, VNC, proprietary...

It would even fit with the DRI model of having core functionality common
to all drivers (DirectFB system module) and specific functions added by
each driver to make it complete (DirectFB graphics driver).

> Would it be hard for you to pick the old FBDev code and adopt it under 
> DirectFB? We dont need our own kernel level infrastructure in order to 
> go on without DRI.

You mean pulling fbcon into user space? There's no win except for some
driver code, but better pull in that and use the devmem system module or
a uio system module to be written :)

-- 
Best regards,
   Denis Oliver Kropp

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

_______________________________________________
directfb-users mailing list
directfb-users@directfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-users

Re: DirectFB without FBDev

[Geert Uytterhoeven]

On Wed, 28 May 2008, Denis Oliver Kropp wrote:
> Geert Uytterhoeven wrote:
> > On Wed, 28 May 2008, Denis Oliver Kropp wrote:
> > > One major bug at the moment is mode switching and pitch values being
> > > wrong. It's dumb to
> > > return the pitch of the variable mode settings in the fixed settings
> > > structure anyhow, but
> > > if you like to start with the above mentioned mission, that's where it
> > > could begin.
> > 
> > Do you care to tell us why this is dumb?
> 
> Ok, the fixed information should not contain information that changes over
> time,
> otherwise it is not fixed, at least that's my understanding of "fixed".

It's `fixed' not in the sense that it can never change, but that it
purely depends on the info in struct fb_var_screeninfo.

> > The pitch depends on the video mode and the hardware requirements,
> > that's why it's in struct fb_fix_screeninfo.
> 
> It would suffice to encode the pitch requirements independent from the video
> mode,
> i.e. just put the pixel or byte alignment into the fixed structure.

What if the pitch requirements depend on the video mode?

There exists graphics hardware where fb_fix_screeninfo.type depends on
the video mode.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

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

Re: DirectFB without FBDev

[Denis Oliver Kropp]

Geert Uytterhoeven wrote:
> On Wed, 28 May 2008, Denis Oliver Kropp wrote:
>> Geert Uytterhoeven wrote:
>>> On Wed, 28 May 2008, Denis Oliver Kropp wrote:
>>>> One major bug at the moment is mode switching and pitch values being
>>>> wrong. It's dumb to
>>>> return the pitch of the variable mode settings in the fixed settings
>>>> structure anyhow, but
>>>> if you like to start with the above mentioned mission, that's where it
>>>> could begin.
>>> Do you care to tell us why this is dumb?
>> Ok, the fixed information should not contain information that changes over
>> time,
>> otherwise it is not fixed, at least that's my understanding of "fixed".
> 
> It's `fixed' not in the sense that it can never change, but that it
> purely depends on the info in struct fb_var_screeninfo.

I'd prefer an ioctl which has input and output fields in the accompanied struct,
so that the resulting pitch is returned to the user space with the same system call.

>>> The pitch depends on the video mode and the hardware requirements,
>>> that's why it's in struct fb_fix_screeninfo.
>> It would suffice to encode the pitch requirements independent from the video
>> mode,
>> i.e. just put the pixel or byte alignment into the fixed structure.
> 
> What if the pitch requirements depend on the video mode?

Haven't seen that, usually either pixels or bytes just needs to be a multiple
of something. In these cases you could simply forbid/fail to choose the pitch and
just return it in the variable structure.

> There exists graphics hardware where fb_fix_screeninfo.type depends on
> the video mode.

Sure, type depends on the pixelformat :)

-- 
Best regards,
   Denis Oliver Kropp

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

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

Re: [directfb-dev] DirectFB without FBDev

[Denis Oliver Kropp]

Denis Oliver Kropp wrote:
> Hi,
> 
> after getting too depressed by the current state of the FBDev backend with the new
> surface core I decided to drop FBDev support as it no longer fits into the architecture.
> 
> If you feel you like to fix the frame buffer device system module or better the frame
> buffer device itself, you're welcome to help the FBDev backend to creep over the 1.2 hurdle...
> 
> One major bug at the moment is mode switching and pitch values being wrong. It's dumb to
> return the pitch of the variable mode settings in the fixed settings structure anyhow, but
> if you like to start with the above mentioned mission, that's where it could begin.
> 
> And while you're at it, please also add an ioctl to just simply set the display offset without
> a virtual resolution and x/y offset values within the whole frame buffer...
> 
> I have no idea why the FBDev backend uses the wrong pitch (4096) after switching to RGB16 which
> should have a pitch of 2048. One out of ten tries did work though. I remember it has been
> working once I added several workarounds and hacks to keep the FBDev backend alive, but somehow
> the code or core have changed, I don't know and I'm not in the mood of spending time on cruft
> like VTs, FBDev etc...

It seems the bug is not happening that often on other
systems, I was using vmwarefb with a 2.4 kernel.

Right now I can only reproduce it when switching from a fullscreen
application back to the window stack and that's due to the weird
workarounds I've added.

> Volunteers are welcome, urgently, I'm going to make a first release candidate of 1.2 tomorrow,
> most likely after removing the fbdev system module.

I'm partly rewriting the FBDev system module now. Without those
workarounds, but a different overall structure it should behave
much better.

Still my wish is to set the frame buffer via byte offset/pitch!

I also forget about those extensions like layer transparency,
scaling, YUV formats, ...

But I suggest everyone planning some more sophisticated stuff
not to start writing a frame buffer driver, but starting off
cleanly in user space with a simple DirectFB driver using the
devmem system module or writing one yourself.

	http://www.directfb.org/docs/ELC2008/elc2008_directfb_gfx.pdf

-- 
Best regards,
   Denis Oliver Kropp

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

Re: [directfb-dev] DirectFB without FBDev

[Denis Oliver Kropp]

Denis Oliver Kropp wrote:
> I'm partly rewriting the FBDev system module now. Without those
> workarounds, but a different overall structure it should behave
> much better.

New commits:
http://git.directfb.org/?p=core/DirectFB.git;a=commit;h=18552ace2ccfd852fac90016844cd30027b432aa
commit 18552ace2ccfd852fac90016844cd30027b432aa
Author: Denis Oliver Kropp <dok-NwL2HUT4ws72VUFvYR39d//2nO7Rh1Op@public.gmane.org>
Date:   Sun Jun 1 15:03:11 2008 +0200

     [fbdev] The big fix[tm]

     Still not working again is support for virtual resolutions with panning,
     not double/triple buffering which works.

  systems/fbdev/fbdev.c              |  518 +++++++++++++++++++++++++++++-------
  systems/fbdev/fbdev.h              |   14 +-
  systems/fbdev/fbdev_surface_pool.c |   53 +++--
  3 files changed, 467 insertions(+), 118 deletions(-)


-- 
Best regards,
   Denis Oliver Kropp

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