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-udeb
I have no real opinion on this. Please go ahead.
ok
* Open a bug against directfb package, asking to add dfbinfo to
directfb-udeb
I'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 KB
Infos 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
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
