# Re: \[directfb-dev\] DirectFB without FBDev

- From: Denis Oliver Kropp \<hidden\>
- Date: 2008-06-01 09:31:34 
- List: linux-fbdev
- Page: https://ratatoskr.run/linux-fbdev/2008/06/13458274
- Thread: https://ratatoskr.run/linux-fbdev/2008/06/13458274/t.md

```text
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/                 |
"------------------------------------------"
```