Bug 1245 - [TRACKER] fb module cleanup
Summary: [TRACKER] fb module cleanup
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/General (show other bugs)
Version: git
Hardware: All All
: high enhancement
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on: 1117 1192 1259 1378 1534 1535 1891 4766 4767 4768 4771 4772 4773 5729
Blocks:
  Show dependency treegraph
 
Reported: 2004-08-30 19:56 UTC by Adam Jackson
Modified: 2008-07-11 14:23 UTC (History)
3 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Adam Jackson 2004-08-30 19:56:10 UTC
we have entirely too many framebuffer cores in X, 14 at last count: afb, cfb,
cfb16, cfb24, cfb32, fb, lmfcfb, mfb, xf1bpp, xf24_32bpp, xf4bpp, xf8_16bpp,
xf8_32bpp, and xf8_32wid.

the following modules could be eliminated by converting users to fb: *cfb*, mfb,
xf1bpp, xf4bpp, xf24_32bpp.  there may be some value in preserving xf4bpp, as it
has some code specific to old IBM 8514 adaptors.  the overlay framebuffer cores
- xf8* - are implemented in terms of cfb; these should be converted to fb, but
this might not be trivial.  afb seems to be needed for amiga framebuffers; it's
not clear to me that it can be replaced with fb.

i'd like to see the list shrink to afb, fb, and xf8* by 6.9.0, though i might be
convinced to let xf4bpp live.
Comment 1 Adam Jackson 2004-08-31 11:43:20 UTC
realvnc (and probably other vnc servers) still depend on cfb, a patch exists at
http://www.mail-archive.com/vnc-list@realvnc.com/msg14387.html
Comment 2 Daniel Stone 2007-02-27 01:24:00 UTC
Sorry about the phenomenal bug spam, guys.  Adding xorg-team@ to the QA contact so bugs don't get lost in future.
Comment 3 Daniel Stone 2007-04-07 14:38:15 UTC
so where do we stand now? right now, xprint still depends on cfb, i believe, as well as sundry drivers which want xf1bpp and xf4bpp.
Comment 4 Adam Jackson 2007-04-08 14:50:28 UTC
We've actually made a lot of progress:

afb:  Still has issues.  mfb-infected.  I think the right thing at this point is to implement this in terms of wfb, since the pixel access wrappers there should be good enough to do the planar->packed conversion

cfb: Only Used by xf8_32bpp.

cfb16: Deleted.

cfb24: Deleted.

cfb32: Only used by xf8_32bpp.

fb: Exists, now also subclassed as wfb, but in a very polite way so I'm okay with it.

lmfcfb: Long since deleted.

mfb: Exists.  Used at compile time by afb, cfb*, and xf1bpp, but not loaded directly by any driver.

xf1bpp: Exists, still used by several drivers.  Really ought to disinfect the accelerated drivers of this and xf4.

xf24_32bpp: Deleted.

xf4bpp: Still exists, see xf1bpp.

xf8_16bpp: Rewritten to minimally wrap fb's overlay code.

xf8_32bpp: Still exists.  This is the hard one to rewrite, since it's for 8/24 packed overlays, despite the name.  I believe only glint and mga use it, so in principle we could just nuke the thing and tell the users of same to cope.  Would really like to have bug #4770 addressed in that scenario, since overlay emulation would be really good to have.

xf8_32wid: Deleted.

And all the non-loadable servers are using fb now (yes, even Xprt).  So basically, if we remove the 8/32 users, cfb is dead.
Comment 5 Adam Jackson 2008-07-11 14:23:17 UTC
I'm calling this one fixed.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.