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

[Sottek, M. J <mat...@in...>]

>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 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.

>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.

>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.

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
examples of grouping unique id's so that they have some derived
meaning. The examples provided are a 5 minute guess at a grouping.

I didn't like the r/g/b/a offset/size because it doesn't handle non
RGA formats and makes it difficult for a driver writer to determine
what the type is exactly. My way it is a simple case statement. The
complicated rendering code that needs the r/g/b/a offset stuff can
look it up in userspace. Using unique ids can support any color type.
Right now if a driver does it's own character rendering it would have
to not only check bpp but either handle all the weird offsets or
check to make sure they are sane. It is just to make the kernel side
easy and leave the hard stuff to user-land.

>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.

The surfaces are just "views" of data. When you are looking for the
physical address of the fb you can query surface #0 to get it, checking
that surface #0 has a type that indicates it is a fb. If you are looking
for a hardware cursor you would just query all the surfaces until you
found one that said it was a cursor. It doesn't have to be in video
memory at all. You just need to know what surface # it is.

If you want to set up a cursor you call fb_set_cursor() if it returns
ENODEV, you've got no cursor. You only need to look for the surface
when you want to write to the cursor, after you've negotiated the
type and stuff.

>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 was against the physical address showing up anywhere too but others were
not. If you wanted to make a frame grabber write to memory directly you
could use the physical address from the surface 0. (or if you had a
surface for an overlay)  Pitch has no meaning to anyone except those who
are accessing the memory directly. Read/write etc. are only referencing
the actual visible memory so this information doesn't belong in
fb_mode_info. In short, the surface view if helps in getting the data
needed for direct access via mmap or some other hardware. For
most writable surface types it is either of device dependent format
(command buffers, depth buffer) or it is defined somewhere else
(cursor, framebuffer).

Surfaces are just the information about the memory. How big, where?
for what? arrangement? dirty?

>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.

Can you write this out completely? I see what you mean about queuing
commands but I fail to see how return values and return data would
happen as the pipe would be somewhat asynchronous and one direction.

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

Could be done that way too but I see a couple issues. First a bitmap
has no priority, how do you know what the client really wanted? My
way the client can just poll until they get one they can live with.

In practice this isn't going to happen this way at all. A client is
going to be written for ONE interface and is just telling the driver
how to behave. If the driver can't do it, the app doesn't run. That
is what would happen in your case too. An app written today supports
the last 5 versions in it's bitmap, 6 years from now the driver
doesn't support any of those so it doesn't work.
Old app + new driver = New driver acts old
New app + old driver = The driver probably doesn't have the features anyway.

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

Correct, as with sound, there is no way the kernel should do
converting of any kind. If you can't put() what the driver is using
then you need to do it in a library, not the kernel. It is too slim
a line to say RGB16->RGA24 isn't hard so I'll do that in the kernel
but YUV4:2:0->YV12 is too hard so I won't do that.

>What is behind di* interface, except slowing things down due to
>additional level of indirection?

There is nothing in there of any speed concern. First, the reason
for the context stuff at all was to keep things that the driver
shouldn't have access to out of it's hands. Things that belong
only to the di layer. Separation is good, it prevents accidents.
(I think that wasn't your point)

I think you were asking about setting the fb_mode_info and such
which DO belong to the driver. The reason for using the interface
is that the di layer is helping the driver out by always keeping
the most up-to-date copy. This way fb_get_* doesn't have to go
down to the driver level. Otherwise you have to have a resource
that is shared. All shared resources need mutual exclusion. What
happens when the driver is updating the fb_display_info structure
and another process queries the structure. If it is shared you
could get invalid results. Then you could add a mutex so this
doesn't happen, but someone will forget and now you've got problems.
This could also happen via a hotplug interrupt so your di layer
can't just provide mutual exclusion at the interface.
With the difb*() everything is easy. Let the di layer do all
the hard parts for you. The tiny loss of speed isn't going to
be detectable anyway. Nothing in there happens on a regular
basis.

-Matt