Re: [Linux-fbdev-devel] API prototype doc

[Sven <lu...@dp...>]

On Mon, Dec 03, 2001 at 05:22:27PM -0800, Sottek, Matthew J wrote:
> 
> >No PC hardware I know (*) interlaces framebuffer with some non-fb related 
> >data. And if fbdev driver decides to put some special data inside - it is 
> >buggy fbdev driver then.
>  
> You are correct, I was searching for an example of when mmap wouldn't work.
> I think for the most part I've given up this search :)
> 
> >You cannot address devices on smaller granularity than page, so I do not
> >understand how you would like to construct such device. I know no device
> >which does that... And nobody forces you to have framebuffer aligned on
> >page - at least matroxfb on Millennium I happily did it in the past.
> 
> Right so if your framebuffer isn't page aligned (both begin and end) can't
> the client run off of the framebuffer memory into any other data in the
> same page? So If you had a command buffer that started right after the
> framebuffer you might be able to accidentally hit it by running off the
> end of the framebuffer pointer. This is an easy fix for the driver...
> just don't do that.

I guess you are speaking about dma buffers here, are you ?

mmm, does all board work so ? 

In the case of the permedia3 and i guess most other 3dlabs boards, the dma
buffers get copied directly from the main memory to the chips command
pipeline, and never use any framebuffer memory.

But then, this is nice hardware, others may not be doing things this cleanly.

> I am backing off all assertions that there are good reasons not to do mmap
> of the framebuffer. The only reason to not allow mmap is that it is hard
> to force apps to stop writing when they shouldn't.

You mean, you can write (or read) data past the one you are supposed to own in
the framebuffer ? 

From my experience (but again, i know only the 3dlabs boards) the only real
problem here, is when two different apps use the framebuffer, and use two
separate space of framebuffer memory has private offscreen memory, and should
not interact. This usually doesn't work so, mainly (in the case of fbcon and X
i am familiar with), each app saves the framebuffer data before releasing the
chip, and i guess it could also clear it so no other app has access to it, and
restores it when they get the chip back.

This may not be the fastest thing around, but i guess such switches are not
done that often, and can acomodate themselves for a little delay, there will
momstly be a resync anyway for changing video modes.

That said, maybe i am missing the point entirely, so please tell me so, or
maybe there are some applications you have in mind that cause a real problem
here ? Maybe these application may be changed in order to work better for
this.

> >No. All OSes I know - although they maybe started with some bright ideas -
> >- sooner or later just gave direct access to videoram for apps - DirectX
> >for Windows, DGA for XFree. 
> 
> Agreed. Although DGA isn't a good success story.

What about DRI then ?

> >I need 80MBps throughput of images from CPU to videoram - it is just 
> >impossible to pass such stream from CPU to main memory, and then from 
> >main memory to videocard with current 33MHz PCI bus and host bridges.
> 
> If you are decoding video you'll have a working copy in RAM anyway, the
> kernel can read directly out of that copy any into the framebuffer. Not
> as fast as MMap for some things but not as bad as copying from
> memory to a temp space then into the framebuffer.

not sure, there were some discutions on some list (maybe X-devel, maybe
dbeian-ppc, dont remember) about using the fb memory directly through some AGP
trick.

Current Xv implementation does a copy from app user space to Xv user space
memory, who then initiate the transfer either directly or through some accel.

> I agree, Mmap should probably stay. We'll just have to work out a way
> to force apps to behave. I haven't given up on the fault handler
> idea.
> 
> >fb_display_info - FB_DISPLAY_*SYNC_HIGH - I did not found into which
> >field they belong - into flags? And there is missing 'Use COMPOSITE SYNC'
> >and 'Use SYNC ON GREEN'? How do you query these capabilities for different
> >modes? 
> 
> Yea, flags. I didn't go through the trouble of working out all the
> #defines that would be needed. I was more concerned with looking at
> the interface from a different point of view. There are lots of flags
> that would need to be added, I was pretty sure they could be
> accommodated with the flags bits.
> 
> You shouldn't need to query for capabilities. You set them and if the
> driver comes back with them unset then it wasn't possible. Just like
> refresh or anything else, try it and see if it works.
> 
> >fb_mode_info - How you came to idea that both RGBRGBRGBRGB and 
> >RGBARGBARGBA should use 24BIT, while you do not use 15BIT for 1:5:5:5 
> >16bpp videomode. There is also no definition for BGR layout - what
> >was wrong with r/g/b/a offset/size?
> 
> I meant RGBnothing not RGBalpha. RGBA is 32bpp.These were just

No, you can ever use RGBA 5551, which is much better than RGB 565 since you
get uniform grays, and you can use the 1bit alpha channel for some nice tricks
(like doing masks in video playback for some GUI elements or such).

Friendly,

Sven Luther