Frans Pop wrote:
(Attilio: Please forward this mail to the directfb list again.) On Saturday 30 September 2006 21:01, Attilio Fiandrotti wrote:To summarize, if no one talks against this, i plan to do the following things tomorrow * Open a bug against rootskel-gtk, asking for linux_input disabilitation on PPC boxes, providing a list of boxes (currently only one) where that module has *not* to be disabled.I've seen Denis say that this is not the optimal way to proceed.For me the test results for powerpc only confirm that g-i support for powerpc should continue to be considered experimental for Etch.
I agree this should be fixed upstream (and dok also said he's going to work on input devices handling issues), but he also suggested to disable linux_input *tempoarily* for laptops, like he currently does on his laptop. Now, i understand you may consider safer not doing this for i386, but please consider the linux_input module was found to be the cause of the most part of crashes encountered on PPC boxes in my recent PPC survey. So, i propose to disable it for PPC *only*, or PPC users won't ever be able to boot the graphical installer: having majority of PPC boxes working doesn't mean the support to g-i on that architecture should no longer be considered experimental.
* Open a bug against directfb package, asking for removal of gfxdrivers from directfb-udebI have no real opinion on this. Please go ahead.
ok
* Open a bug against directfb package, asking to add dfbinfo to directfb-udebI've just taken a look at the output of this tool and, to be honest, I'm somewhat disappointed at the info it provides: it does not even identify the framebuffer device/driver used. The only really useful info seems to be the input devices and to use up 10k just for that seems excessive.
About datas provided by dfbinfo i can only guess they have a meaning we cannot understand completly right now, and i think dok must have had a real reason asking for its inclusion into core directfb package. Framebuffer device used can be easily detected from /proc/fb file (or better grep'ing lspci output) like i did in the PPC survey. If we remove gfxdrivers from libdirectfb-udeb, space usage will vary (roughly) like this
removal of gfxdrivers - 500 KB add of GTK bladr theme + 100 KB add of dfbinfo + 10 KB total - 390 KBInfos about DFB input devices cannot be found elsewhere, and because input devices recognition/management with DFB is currently a big headache for us, i belive they are indeed very useful.
* Open a bug against rootskel-gtk, asking for inclusion of GTK Bladr theme (which i recently stripped down to ~100 KB)That is not really needed, it is planned already, but I'm waiting for a new version of fontconfig. That said, a bug report with the cleaned up version would be useful for future reference. Did you also strip down the configuration file for the theme?
No, i didn't because i don't know where put my hands, but of course i'll provide a a pointer to the bladr tarball without unneded PNGs i prepared, this will help keeping track of this issue.
Cheers, FJP This is the output of dfbinfo when run inside g-i in vmware:
cheers Attilio