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

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

On  4 Dec 01 at 9:15, Sottek, Matthew J wrote:
>  
> I'm ok with leaving out policy, but the problem is that we have no
> way to notify the client in a timely manner either. They would
> have to poll the surface to look at the status.
> 
> So what should be done on a vt switch?

App uses all (or needed of) VT_LOCKSWITCH/VT_UNLOCKSWITCH ioctls + 
VT_SETMODE (fields acqsig, relsig) ioctl if it needs direct access to
fb.

> I think it may be ok to zap() someone's mmap during a vt switch but
> otherwise make them work out their own policy. vt switches are
> slow anyway.

Why do you think that VT switches are slow? And tearing down existing
mappings is not trivial.
 
> I am unsure of how XFree handles this. Does the X server trap the
> vt switch sequence, call leave_vt() then switch the vt?

LOCKSWITCH + SETMODE to deliver signals on console switches.
 
> >You need busaddress for this. Bus address != physical address
> >!= virtual address, see PPC.
> 
> Just copying what was there for sysmem_start. Bus address is confusing
> to platforms who don't have them just like physical address is
> confusing to you.

You need physical address for mmap on /dev/kmem, while you need busaddress
for doing DMA transfers from other PCI busmasters to videoram. 

> >fd = socket(PF_UNIX, SOCK_DGRAM, 0);
> >connect(fd, (struct sockaddr*)&(struct sockaddr_un){AF_UNIX, 20,
> >"/dev/gfx/fb0/command"}, 128);
> 
> While I do like the features of this one better, It scares me
> a little. I don't like having network behavior different than
> local, it should be transparent, and the complexity/overhead
> is a little higher. This could be bad for small
> fb_set_cursor_pos type commands.

You can use UDP if you want same behavior on local - but I do not
think that you'll get remote behavior same as local anytime. For remote
access you must do authentication, authorization, encryption and couple
of other things you do not require on local system because of someone
else already took care of auth*, and you do not need encryption because
of nobody without root priviledges can see what you are doing.

> >No. Kernel driver should provide only one API, unless new one is not
> >superset of old API.
> 
> I don't agree. The kernel needs to provide a consistent API. For
> ioctls this means you really should not be changing them after they
> become widely used.  Since we are moving to a more advanced command

It is userspace library business to do these conversions. Kernel should
support one, at most two for transition period, interfaces. If you are
upgrading kernel, upgrade your userspace too. If you are not going to
upgrade kernel - no problem, kernel API does not change.

> >(mainly) about monochrome -> current fb type for painting
> >characters on the screen. And couple of hardware can do YUV
> ><-> RGB on the fly.
> 
> I have to think about this. YUV<->RGB is probably going to need
> some other interface that goes with overlays. Color expanding
> blits are a valid thing that I missed.

They are same from my (and from G400) viewpoint. I have byte array,
source color organization, and framebuffer color organization. And
either hardware can do that conversion, or it cannot.
 
> >two displays are provided from one memory pool? Will di layer just
> >provide dummycon for VT which is incompatible with current hardware 
> >configuration?
> 
> I'm not sure what you mean about dummycon for VT?
> 
> Two framebuffers with two (or more) displays has two fb contexts. Just
> like now... you do the whole thing as two drivers, two privs and all.

You have two framebuffers, two displays, two fb contexts, and only one
memory they share. Now you do

VT #1  belongs to fb #0
VT #2  belongs to fb #0
VT #11 belongs to fb #1

Your videocard has 8MB total. Now you select 1024x512/32bpp on all
VTs, each uses 2MB of videoram. VT#1 and VT#11 are visible. Now you change
VT#1 size to 1024x1536/32bpp - consuming 6MB + 2MB. Now you switch to VT#2,
and resize #11 to 1024x1536/32bpp - this is again valid resolution, as
2MB + 6MB <= 8MB. But now, when you switch back to VT#1 - oops, VT#1's
resolution needs 6MB, VT#11 needs 6MB, total 12MB. Impossible...
So *_set_var or how is it named in your API, fails, and VT layer must
be able to cope with that. Temporary moving VT from fbcon to dummycon,
or refusing to switch VT, are two possible solutions.
                                            Petr Vandrovec
                                            van...@vc...