fresh checkout with #define BuildLowMem YES in host.def refuses to build: make[4]: *** No rule to make target `../cfb/cfb8cppl.c', needed by `cfb8cppl.c'. Stop. make[4]: Leaving directory `/xorg/bz3043/programs/Xserver/lmfcfb' make[3]: *** [includes] Error 2 this indicates that this configuration has been broken for a long time. XFree86 dropped this file five years ago, and Xorg dropped it in 6.7 (granted that was only one year ago). the BuildLowMem imake flag is not documented anywhere, and no configurations define it by default, so the odds are low that this change will affect anybody. cleaning this out requires dropping all the BuildLowMem stanzas from the Imakefiles, treating the LOWMEMFTPT preprocessor token as undefined everywhere, and removing programs/Xserver/lmfcfb from HEAD.
Created attachment 2467 [details] [review] kill-lmf-1.patch this would need to be accompanied by 'cvs rm programs/Xserver/lmfcfb'
ajax: Before you kill the code... would the LowMem setting still be usefull for Xserver's in embedded environments ?
doubtful. the code appears to be of early Sun vintage. in particular most of it is in cfb code, with only a bit in the font lib to select a subset of font engines. cfb doesn't get used on embedded platforms, and kdrive already has compile-time selection of font engines. there's certainly value in supporting low-memory configurations, but this particular option isn't very effective at providing a low-memory profile.
(In reply to comment #3) > doubtful. the code appears to be of early Sun vintage. OK... I'll CC: Alan Coopersmith to have a look... > in particular most of it is in cfb code, with only > a bit in the font lib to select a subset of font engines. > cfb doesn't get used on embedded platforms, > and kdrive already has compile-time selection of font engines. Erm... the LowMemCfb stuff predates Kdrive and was AFAIK working in releases <=X11R6.6. Releases >= X11R6.7 pulled-over some things which Xfree86 did not care about but that does not mean we should act the same way... > there's certainly value in supporting low-memory configurations, but this > particular option isn't very > effective at providing a low-memory profile. Alan: Do you think this option is somehow still usefull or should it go away ?
2nd try to CC: Alan...
As far as I know, it's not from us - I've never seen anything like it in any current tree at Sun and we don't have anything similar that I'm aware of. I know of no use for this code, and would probably not even notice if it disappeared completely.
applied to head, closing.
(In reply to comment #7) > applied to head, closing. I really really wish we would kill things less fast and check first what the exact purpose of the stuff is and who added it... but it seems noone cares (except me) to do an investigation - which may be an ill omen for the future.
> I really really wish we would kill things less fast and check first what the > exact purpose of the stuff is and who added it... but it seems noone cares > (except me) to do an investigation - which may be an ill omen for the future. stop with the conspiracy theories. i did check. it was added by the old xorg consortium in 6.4 - that's eight years ago, btw. it hasn't worked in the de-facto SI in five years. it primarily affects cfb, which is ugly, buggy, slow, and unmaintainable, and unused on modern embedded platforms. the other feature it had was compiling out the scalable font backends, which is trivial to replicate with the loadable server - or the static one for that matter. lmfcfb was dead code.
(In reply to comment #9) > > I really really wish we would kill things less fast and check first what the > > exact purpose of the stuff is and who added it... but it seems noone cares > > (except me) to do an investigation - which may be an ill omen for the > > future. > > stop with the conspiracy theories. Which "conspiracy theories" (this argument is for the trashcan) ? I just want a clear and documented way for code+feature depreciation to avoid that stuff gets killed which may be in use by other people. Just think about it what happens when a maintainer leaves the boat for two or three months and then comes back - seeing that all of his/her work is being ruined (that happened already with active code (I am not thinking about BuildLowMem+DPS here)) ... > i did check. it was added by the old xorg > consortium in 6.4 - that's eight years ago, btw. it hasn't worked in the > de-facto SI in five years. Do you mean Xfree86 ? This was never the SI for any platform (except the x86-centric ones (Linux etc.) where it had a more or less defaco status because noone was working with XC directly). > it primarily affects cfb, which is ugly, buggy, > slow, and unmaintainable, Howver cfb is still being used and it would be nice to not kill it as some vendors such as Sun have far more advanched versions of cfb which can deal with stuff such as MPG+multiple over- and underlays - something which the "fb" code lacks. > and unused on modern embedded platforms. the other > feature it had was compiling out the scalable font backends, which is trivial > to replicate with the loadable server - or the static one for that matter. > > lmfcfb was dead code. Agreed. My primary complaint is that the analysis above was not in the bug and that it's still not clear who added it (and for which purpose) and that noone tried at least to contact this person.
> > i did check. it was added by the old xorg > > consortium in 6.4 - that's eight years ago, btw. it hasn't worked in the > > de-facto SI in five years. > > Do you mean Xfree86 ? This was never the SI for any platform (except the > x86-centric ones (Linux etc.) where it had a more or less defaco status because > noone was working with XC directly). you have a spectacularly myopic view of history. > Howver cfb is still being used and it would be nice to not kill it as some > vendors such as Sun have far more advanched versions of cfb which can deal with > stuff such as MPG+multiple over- and underlays - something which the "fb" code > lacks. sun's cfb code is not in Xorg, therefore it is irrelevant. i have no doubt that it is superior to the cfb code in Xorg, but until and unless it is included in Xorg i have no motivation to care about it. the code that Sun maintains out-of-tree is Sun's maintenance burden, not ours. > Agreed. My primary complaint is that the analysis above was not in the bug and > that it's still not clear who added it (and for which purpose) and that noone > tried at least to contact this person. the header at the top of the imakefile from the 6.4 release names the author as 'msr', who i assume from the release notes is M. S. Ramesh. there was no other documentation in the 6.4 release about this feature. i have had no success in finding an email address for this person. you're welcome to try.
Sun's cfb is not very different from the Xorg cfb, and most of the differences I know of are XFree86 additions we never pulled in, like the cfb24 support. Our few enhancements (mainly Solaris performance improvements, bug fixes, and tweaks needed by certain Sun frame buffers) have been low on the priority list for contributing back since it seemed rather pointless given the lack of drivers using cfb and it's deprecated status. All the multiplane group and related bits are down in the Xsun DDX layers, not in cfb. As for who was the SI, at Sun we had unofficially gone to sort of a dual-SI model, pulling changes from both X.Org and XFree86 as upstreams for Solaris/Xsun, and were thinking of making it official shortly before the "time of troubles" began, but never did.
The DefaultFontPath setting was removed completly from config/xf/X11.tmpl.
commited to HEAD /cvs/xorg/xc/config/cf/X11.tmpl,v <-- config/cf/X11.tmpl new revision: 1.48; previous revision: 1.47 /cvs/xorg/xc/ChangeLog,v <-- ChangeLog new revision: 1.902; previous revision: 1.901 marking as 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.