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

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

On  3 Dec 01 at 17:22, Sottek, Matthew J wrote:
> >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.

Yes. It would be buggy driver... On MillenniumI I have nothing before,
and nothing after (as MillenniumI/II does not have cursor image stored
in framebuffer), so only thing user can see is garbage from other VT.
But as we do not clear this anyway on VT switch, it should not matter.

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

Why to stop them? If we do not provide full virtualization for them,
we should not put any additional policy on their behavior.
 
> >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

You need busaddress for this. Bus address != physical address != virtual
address, see PPC.

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

Bidirectional pipe. As pipes are unidirectional, it must be either
character device, or (maybe better, as it has needed semantic) UNIX datagram
socket.

You write some command into socket. You must write command in one chunk -
- use writev if you need scatter/gather. write either fails, or completely
succeeds (due to datagram socket nature). If write fails, well, you are done,
command failed and you'll not hear from fbdev driver back.

If write suceeded, you can read one datagram from socket. This chunk will
contain result of your command, plus optionally data returned by command.

It has nice feature that you have automatically queue in the kernel,
if you'll access it through 

fd = socket(PF_UNIX, SOCK_DGRAM, 0);
connect(fd, (struct sockaddr*)&(struct sockaddr_un){AF_UNIX, 20, "/dev/gfx/fb0/command"}, 128);

you can use same access for networked gfx, just using network socket
instead of local unix socket, and datagrams are by definition atomic,
and every client has its own socket, so if one fails to read answers, 
it does not affect others.

If you can trust to apps, using SOCK_STREAM is definitely better, but
in such case you must use some length-prefixed encoding for commands,
as request boundaries are not implicitly passed through communication
channel. On other side you are not limited by 30-60KB kernel limit for
datagram size.

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

Highest one. 

> 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

No. Kernel driver should provide only one API, unless new one is not
superset of old API.

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

Hardware can do that. We are not talking about RGB16->RGB32, but (mainly)
about monochrome -> current fb type for painting characters on the
screen. And couple of hardware can do YUV <-> RGB on the fly.
 
> 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

Hm, maybe I understand.

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

But someone else can do it properly finegrained...

And when I thought about it during night, how this API address when
two displays are provided from one memory pool? Will di layer just
provide dummycon for VT which is incompatible with current hardware 
configuration?
                                                            Petr