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

[Petr V. <VAN...@vc...>]

On  3 Dec 01 at 16:21, Chris Wright wrote:
> > The extra pitch-width area isn't useless. You can put other surfaces there.
> > You think of the area as being broken up, but really it is just a thinner
> > area with the same pitch as the framebuffer. i.e. if your framebuffer is
> > 800x600 at 16bit, on Intel hardware you have a fb pitch of 2048. That
> > is an area of 448x600 with a pitch of 2048 that can be used.
> 
> true true, it would most likly be used as an off screen buffer.  I am
> simply used to having very small pitches (3 bytes or less from24bpp
> misalignment), but no reason very large ones couldnt exist.  mmaping that
> would be extremely insecure

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.
 
> > Maybe this reason works, what if the framebuffer isn't page aligned (both
> > the
> > beginning and the end) then you'd get access to memory that you shouldn't.
> > Drivers could just be careful not to put things that you shouldn't have
> > access to in the overlap I guess.
> 
> to me, that'd be a driver technicality, but it does provide an example of
> where things can go wrong =)

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.
 
> > be more work than it is worth. Without mmap lots of things become trivial
> > that would otherwise be very difficult. With mmap you get a speedup in
> > some operations, but is it worth the pain?
> 
> to me, the speed up would be a very large asset, esp in regards to raw
> framebuffer data reads/writes.  this day in age, hardware is so
> rediclously fast that we can realistically say 'hey, lets throw out memory
> access completely, and let kernel handle it' and not expect our systems to
> be rendered unusable.  but there is a large base of systems that take huge
> performance hits; not good if linux is to grow off of the server and onto

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. 

What I see here is that useful parts of fbdev are removed in the name of 
supporting some obsolete or nonfunctional hardware, or in the name of 
supporting remote fbdev. Well, make mmap optional, but do not remove it.

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. After 
I'll have 1Gbps network card in each computer around, with 64bit 66MHz PCI, 
maybe I'll think that I may need remote fbdev. But until then I'll leave 
remote access on app level - I'll run mplayer remote, instead of feeding 
uncompressed pictures over the wire.

And now few comments to Framebuffer Interface proposal, draft 1, from
Matt Sottek:

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? 

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?

fb_surface_info - Note that existence/non-existence of FB_SURFACE_TYPE_CURSOR
does not tell you anything about existence of hardware cursor - there
is hardware which does not store cursor body in framebuffer.

Having physical address here is wrong - what is reason for having it here?
Cannot it be relative to something else? And as you do not tell anything
about contents of these areas, what is pitch for?

I do not agree with semantics of /dev/gfx/fb0/command. It should act
as normal pipe - no seeks, you can queue commands and then get command
results back.

fb_set_interface - pass bitmaps through, so userspace APP can offer
which versions are supported, and kernel can reply back which version
was negotiated.

I see no format info on any fb_put() op - either driver or kernel.
Same for fb_get().

What is behind di* interface, except slowing things down due to
additional level of indirection?
                                    Thanks,
                                            Petr Vandrovec
                                            van...@vc...

(*) In 1985 there was (czecho)slovak computer PMD85 which interlaced
picture with system variables - but even at that time if you'd replace 
OS, you could use this extra pitch for whatever you want (e.g. for nothing).