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/ |
"------------------------------------------"
_______________________________________________
directfb-dev mailing list
[email protected]
http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
