[Libdlo] udlfb flush on close (Was: Basic PNG and SVG display)

[Roberto De Ioris]

> Phil Endecott wrote:
>> if I open the device, write an image and close it, will your
>> driver flush to the hardware on the close?
>
> Here's some code to do this:
>
> static int dlfb_release(struct fb_info *info, int user) {
>           struct dlfb_data *dev = info->par;
>           image_blit(dev, 0, 0, info->var.xres,info->var.yres,
> info->screen_base);
>           return 0;
> }
>
> static struct fb_ops dlfb_ops = {
>
>           .fb_setcolreg   = dlfb_setcolreg,
>           .fb_fillrect = dlfb_fillrect,
>           .fb_copyarea = dlfb_copyarea,
>           .fb_imageblit = dlfb_imageblit,
>           .fb_mmap        = dlfb_mmap,
>           .fb_ioctl       = dlfb_ioctl,
>           .fb_release     = dlfb_release,
> };
>
>
> You can now do something like
>
> # dd if=/bin/bash of=/dev/fb0 bs=1600 count=480
>
> and see a load of rubbish on your screen.  (BTW, does anyone know how
> to convert an image to 565 16-bit raw RGB?  I was expecting there to be
> some pnmtorgb utility but I can't find one.  ImageMagick's convert will
> convert to 24- or 32-bpp raw RGB, but AFAICT Roberto's code doesn't yet
> support 24bpp.)


I think its a good thing, i will add it to the 0.2 codebase.

Implementing 24bit support is on my todo list, but only after the
inclusion in the staging tree (as Greg asked).

>
> Now, how can we add double-buffering to that?


If you follow the mmap+ioctl approach (as in the mplayer patch) you do not
need a double buffer to reach good performance without flickering.

But probably, to implement compression, we will need a second buffer in
the kernel (to track pixel differences) that can have a lot of use (even
if maintaining two such a big buffer would be overkill on embedded
systems)



Roberto

>