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

[Matt S. <mat...@ho...>]

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

I could see a physical pointer in a mode based data structure (similar
to "var") with the knowledge that it can be 0 if the fb is not
directly accessible. Also such a data structure would be where you
could find an "offset" and "size" to use as mmap parameters. "size"
being 0 if mmap isn't possible.

>The framebuffer itself is pretty safe to export to userland.

I assume you mean to allow people to mmap the framebuffer? Yes this can
usually be safe, but only the screen data. Most chips use graphics
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.

MMap is essential for lots of applications. I'm all in favor of allowing
it where possible. This isn't the kind of direct access I was against.
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.  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.

>MMIO can be tricker. The area of graphics resource management is really
>complex. For now I'm just aiming to get a clean seperation of the
>console system out of the framebuffer layer. 

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.

>Personally I like to see the day when DRI and the fbdev layer are
>merged but that will be awhile.

Yes me too, but a lot of cleanup needs to be done in fb land before
anyone should consider it. The drm code is pretty well designed and
doesn't have the kind of cruft that has built up on the fb interfaces.

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.

-Matt