Hi gents,
This post was originally posted to the kernel-janitors list. After which
I learned there was an active development-list for linux-framebuffer stuff.
-------------------------
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.)
- It relieves maintenance of the common frambuffer code, because we don't have
to keep fb.h in sync.
- It also relieves the maintenance for the driver developer
because he can add new cards without having to request modifications
to public framebuffer code.
=> cleaner fb.h
Could we make this a general guideline?
I have created a patch for the savage driver and fb.h to give an idea
how this would look like. It has no impact on the other fb drivers.
Best regards,
Henk Vergonet
This post was originally posted to the kernel-janitors list. After which
I learned there was an active development-list for linux-framebuffer stuff.
I'm afraid you will never see this reply, as rememberme@systol.god.lan won't
resolve....
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).
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
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@systol.god.lan won't
resolve....
It is intentional, but if it's a problem I can fix it.
quoted
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 ;)
Best regards,
Henk
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
From: Ville Syrjälä <syrjala@sci.fi> Date: 2005-02-28 13:41:01
On Sun, Feb 27, 2005 at 11:17:15PM +0100, Henk Vergonet wrote:
On Sun, Feb 27, 2005 at 07:28:47PM +0100, Geert Uytterhoeven wrote:
quoted
On Sun, 27 Feb 2005, Henk Vergonet wrote:
I'm afraid you will never see this reply, as rememberme@systol.god.lan won't
resolve....
It is intentional, but if it's a problem I can fix it.
quoted
quoted
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.
And that is exactly how DirectFB uses it. Case closed :)
--
Ville Syrjälä
syrjala@sci.fi
http://www.sci.fi/~syrjala/
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click