Re: [Linux-fbdev-devel] Future of Framebuffer

[Paul M. <pm...@mv...>]

On Thu, Oct 04, 2001 at 04:58:53PM -0700, James Simmons wrote:
> > > I have spoken about this before. I like to see both interfaces merge =
in
> > > the future. Especially with the desire to move from traditional device
> > > files to device filesystems. In the future their will be a graphics
> > > frilesystem to replace the two. Well that is my dream. Of course thei=
r are
> > > a few issues on design with DRI which I will not go into here. =20
> > >=20
> > This sounds like a potential Ruby issue to me (well, the FS part anyway=
s)..
> > how about starting a module for it (or hacking it into the existing tre=
e)?
>=20
> We could but it would be a huge job. Alot of devfs tinkering.=20
>=20
Why deal with devfs tinkering? It would make more sense to implement it as =
its
own native virtual fs. As an example.. could have something like /dev/gfx a=
s a
top level mountpoint for the fs, and then just mount on that (wouldn't matt=
er
if it were devfs or not).

As far as general interfaces go.. a drop-in replacement for the ioctl()'s
really wouldn't be that big of a deal.

For each device that registered with the system, things could be done like:

/dev/gfx/
    0/
        fb
	cmap
	...
	mode
    1/
        fb
	cmap
	...
	mode

and so on, and so forth..

/dev/fb{,/}0 would simply be a symlink to /dev/gfx/0/fb.

FBIOGETCMAP/FBIOPUTCMAP can be done away with by doing reads and writes to =
the
/dev/gfx/0/cmap dentry. Just as all other GET/PUT routines can be done away
with.

Instead of trying to do "special" dentry manipulation in the fs itself, I
think it'd make more sense to just provide a few common interfaces.. Devices
only really need to register themselves with the system.. it's up to the
fb layer to deal with creation of the dentrys and dealing with any kind of
special requests. (Just as it would the requirement for any other subsystem
(DRM anyone?) to deal with special files and registering callbacks with
the fs for them).

The fs itself only needs to do a few things.. provide a few routines for
device registration, and for registering callbacks. In the event that no
callback is provided (or no flags like read-only are set on the created
file), generic dcache routines can be utilized instead..

This could all be done with just having a small structure that contained
a pointer to the dentry struct and a pointer to a set of routines that
callbacks can be assigned to. (Then just check for the existance of a provi=
ded
callback registered with the dentry when things were allocated, and either
use those, or fallback on defaults).

Another advantage of this system is that people who have special needs with
the system can simply write a module that sets up the files it wants, and
registers some callbacks and have it either globally applied or limit it
specifically to a specific card.. Reducing the need for adding ioctl()'s.

All in all, this really shouldn't be that big of a deal.. I don't think an
initial implementation should be difficult at all.. laying out the API
would really be the biggest trick.

Comments?

Regards,

--=20
Paul Mundt <pm...@mv...>
MontaVista Software, Inc.