On Sun, Feb 27, 2005 at 07:28:47PM +0100, Geert Uytterhoeven wrote:
> On Sun, 27 Feb 2005, Henk Vergonet wrote:
> I'm afraid you will never see this reply, as rememberme@... won't
It is intentional, but if it's a problem I can fix it.
> > I want to propose to localize the maintenance and registration of the
> > FB_ACCEL_ id's and remove it from the public fb.h include file.
> > Motivation:
> > - This removes an unneeded dependency to fb.h if an additional cards/chips are
> > introduced. (These id's are only interesting for the driver anyhow.
> > Only fbset will print out the id, but I'll doubt this is used by anyone.)
> Yes, it's used by userspace apps that need to know the graphics card type (e.g.
> DirectFB and the good old XF68_FBDev).
My point is not that there are no userspace utils that use it. But that
we should lose this identifier in the public interface eventually because it introduces unneeded dependencies as stated in my earlier post.
If it's used by userspace in any other way than for pure informational purposes:
For example to make certain assumptions on hardware capabilities, locations of specific hardware registers ...) then that's ok but should be considered as a make-shift solution until we have found a better solution drivers/API.
I know this may be only a small issue to most, I am sure there are more pressing issues, but small cleanups in the fb interface will eventually pay of in the long run.
What do we think developers...
Do we think it's a good idea to remove the FB_ACCEL register in the fb.h in the future, or is it a no-go?
If nobody thinks it's a good idea I'll shut up, (for now ;)