RE: [Linux-fbdev-devel] fbdev API problems

[James S. <jsi...@tr...>]

> >> Currently mmio and fb pointers are in a PUBLIC data structure, a data
> >> structure that is defined for everyone using the fb interfaces, both
> >> kernel side and user side. 
> 
> >That is so you can do things like use the physical memory address of
> >the framebuffer to display a image from a TV card into it.
> 
> No doubt, as you state, there are applications that would need the
> physical framebuffer address. The problem is that when you just leave
> a pointer laying around in a public data structure there is no way
> for a user application to know when the pointer is valid and when it
> is not. If a unsuspecting TV capture card tried to use my physical
> address without knowing that I only have 64k banks the whole system
> would come down hard.

Ah. You are talking about having a real RRM (rendering resource manager).
When a process open /dev/fb or DRI it should be registered with the RRM.
Then when someone does something global like change the graphics
resolution the RRM sends a signal to all the processes that are using the
graphics card resources. As for the 64k bank sitution you can use VM
tricks to make it appeard linear to userland. If you something really
bizarre then you add something on the order of:

#define FB_AUX_TEXT_MDA         0       /* Monochrome text */
#define FB_AUX_TEXT_CGA         1       /* CGA/EGA/VGA Color text */
#define FB_AUX_TEXT_S3_MMIO     2       /* S3 MMIO fasttext */
#define FB_AUX_TEXT_MGA_STEP16  3       /* MGA Millenium I: text, attr, 14

This tells userland youhave something weird so watch out.

> memory of some type for dma command buffers. Most chips cannot safely
> give you full access to such memory areas. The sysmem_start and
> sysmem_length seem to cover the whole graphics region, not just the
> visible framebuffer. This is likely not safe.

Then the driver is broken. This wouldn't be a first :-(

> Mmap IS a driver interface. I can do all kind of tricks in the driver to
> make sure a user who mmaps the framebuffer only gets access to what they
> are supposed to.  In my stolen memory driver I have zero-page fault
> handlers to map and unmap regions while changing memory banks on the 
> fly.  

Nice tricks. 

> I can't do this when the kernel dereferences a kernel-virtual
> address as is done in the logo code. There is no page fault handler for
> me to catch.

Don't worry this will go away in 2.5.X. The virtual poniter will remain
for cards that need it, lacking any kind of acceleration. Since most cards
are acclerated, even most embedded chips, the virtual pointer becomes
optional. That is the key point. It is optional. That pointer then is only
accessed in the software emulated accel functions that are needed. 

> MMio is a very different animal. Most mmio regions are not safe for
> untrusted userspace binaries to access. This is why such access is 
> limited to root. Further there is no generic use for these mmio regions,
> only a userspace driver would know what to do with them. Certainly a
> userspace driver and kernelspace driver that are working together should
> be able to work out a way to share the locations they need without
> leaving them lay around in public.

It doesn't have to be root. DRI allows normal clients to use the MMIO
regions. The key is that you have a RRM that is the guardian angel. If a
process does the naughty you kill it and reset the accel engine.

> I would really like to get as many people looking at the whole fb
> interface with a very critical eye. 2.5.x is the best opportunity we
> will have to make drastic changes. We will have a very long time
> before 3.0.0(?) to get things in shape. I don't want to settle for
> half-done redesign when we could really make a good solid base to
> build on for the next several years.

I have been working on the fbdev api since janurary 1999. Part of it went
in but unfortunely the TTY/console system lacked the power to allow the
rest in. Now I have rewritten the console system to handle it. In the
process I have realized how I could write wrapper until the TTY/console
system gets cleaned up by me.