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

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

On  4 Dec 01 at 11:12, Sottek, Matthew J wrote:
> >App uses all (or needed of) VT_LOCKSWITCH/VT_UNLOCKSWITCH ioctls + 
> >VT_SETMODE (fields acqsig, relsig) ioctl if it needs direct access to
> >fb.
> 
> Ah, but we have an issue here. The X server is a trusted binary,
> therefore we can rely on it to behave. Fb apps are not trusted
> therefore we have to make sure they behave. Just like the DRI only
> allows access when you have the lock, and you can't get the lock
> when you are switched away.

Anything what can mess my console must be trusted. More or less.
If application does not have these right, kernel must not postpone
VT switch until app answers, so only unmapping & delivering signal (SIGBUS) 
to app is possible.

> Two apps on one VT is policy, two apps of different VT's is supposed
> to behave like two apps on different computers. It isn't policy,
> it is kernel enforced.

It is impossible. VTs are virtual terminals, fully virtualized, while
there is only one underlying fb - so apps have to know about each
other, and have to know about VT concept, if they want to support it.
If they do not -> suid & LOCKSWITCH.

> >Why do you think that VT switches are slow? And tearing down existing
> >mappings is not trivial.
> 
> A vt switch console<->XFree takes a couple seconds on some hw,
> plus you may have to resync the display anyway. zap_page_range()
> happens very fast in comparison, not trivial but shouldn't be
> eliminated on grounds of slowness. Perhaps eliminated because
> it is scary, but not slowness :)

It is bug in X, not anything else. It is true that XFree mga driver
reads whole 64KB EEPROM through i2c on startup - but it is just
silly driver. I can switch from fbtv to another console in less than
20ms (== sooner than TV field finishes).

> >You need physical address for mmap on /dev/kmem, while you
> >need busaddress for doing DMA transfers from other PCI
> >busmasters to videoram. 
> 
> Right, but we don't need to tell anyone where to mmap on /dev/kmem.
> If they want to mmap they should use the fb. We only need to
> provide them a way to do DMA... so that's a bus address for PPC
> and a physical address on x86. We can just call it dma_address.

It is bus address on x86. It is just happy coincidence that bus address ==
== physical address. It is bus address by definition...
 
> This all depends on what Network Transparent means to you. Doing
> read/write on a character file works over NFS and then you don't
> need to worry about authentication. Network connections from an
> untrusted machine need some other layer of authentication but that
> should happen in some root daemon. Assuming that some filesystem
> can be network exported you should be able to use the device from
> another trusted machine, that's all I was trying to achieve.

And who is listening on other end of wire if you'll use NFS read+lseek+write
solution? How you'll ensure that change is propagated through wire,
and not cached back? Besides that no system I have interconnected offers
NFS for writting - it is far too dangerous without hardcoded ARP tables.
 
> When you want to set a mode you have to see if it fits, including
> the information about what the other context is using up. If you
> can't fit the new mode you do one of two things. Either don't

It fits. Only VT level knows resolution of other VTs. And if fbdev
should know this itself - then do not change API at all... I see no
reason for change then...

> In the case where this happens without the user requesting it.
> (Vt switching to the two "large" modes) you'll get a fb_set_mode()
> from the di layer. The driver can either change the requested
> mode and apply it, or change the "other_context" and set the
> requested mode. Either way one VT is altered... can't make
> them both happy.

Driver will refuse to set mode you requested on console switch.
 
> The driver is supposed to return success at all costs when it
> gets a fb_set_mode(), even if it has to alter the mode greatly.
> The driver gets to decide what is best, if the user wants to
> be sure, it should test the mode first.

He tested it. It worked. Then he changed something else, and now 
kernel refuses previously working mode. It is possible to split
memory on driver load for 24MB for fb0 & 8MB for fb1 - but why if
you can do it dynamically. At least I hoped that it will be possible
with new APIs.

And no, I cannot change mode greatly, current console will not survive
if you'll change vc_cols/vc_rows in console switch, besides that it
violates layering.
                                            Best regards,
                                                Petr Vandrovec
                                                van...@vc...