Denis Oliver Kropp wrote: > Sven Luther schrieb: > >> On Sat, Sep 30, 2006 at 05:17:05PM +0200, Loïc Minier wrote: >> >>> On Sat, Sep 30, 2006, Sven Luther wrote: >>> >>>> Also, if we want to get this solved, we need have an easy way for >>>> users to >>>> debug this issue, and "the other ways" you mentioned are not going >>>> to be very >>>> helpful in this. >>> >>> Would it be possible to simply take the libdirectfb-bin .deb and unpack >>> it? >> >> >> It should be possible, and then wget the binaries. >> >> I still do believe that it would be lightyears more userfriendly to >> have those >> binaries in a .udeb, which can be included in the ramdisk while we are >> investigating this issue, and later is available for install if one >> wants, but >> Frans has fear of bloating the archive or maybe just because it was me >> proposing it. How big are those two binaries anyway ? a few tens of KBs ? > > > dfbinfo is 8.8K > > dfbinfo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for > GNU/Linux 2.6.0, dynamically linked (uses shared libs), for GNU/Linux > 2.6.0, stripped > > > df_dok is 69K, but it also requires some images and loaders for PNG, > JPEG, GIF, TTF. > > So for simple graphics tests, as dfbinfo has no graphics, df_dok would > be a huge "next step". You could use df_particle, which doesn't load any > font or image, doesn't require additional DirectFB modules and is just > 5.7K here in binary size. Unfortunately, it uses a lot of floating point > and sin/cos IIRC. > >> But anyway, our mighty leader has spoken, there is nothing a poor >> outcast like >> me can do about this, and this kind of stuff is clearly not very >> motivating >> for me to help solve issues, i hope others will jump in. > > > I think at least dfbinfo is mandatory in a system with a shell. It's the > standard diagnostic tool of DirectFB, like xdpyinfo for X11. >
I belive dfbinfo would be a very usefult tool for testers when reporting issues reated to the graphical installer: it generates debug input which could be easily and automatically saved inside installation reports or somewhere else. About the df_dok tool, currently directfb udeb includes the png image provider and we also have a png image in the ISO (the banner used in the g-i). I understand size matters: as tests performed up to this point indicate there are no drawbacks in disabling gfxdrivers, i suggest again to move them out of libdirectfb-udeb, saving up ~500Kb of space in the ISO that may be used to package the GTK Bladr theme and some dfb diagnostic tools. Tests done up to now tell us there is only a PPC box model (PowerBook6,7) which currently needs linux_input to be disabled, so it's safe (for now) disabling linux_input, as also dok suggests as a temporary workaround, on PPC boxes. 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. * Open a bug against directfb package, asking for removal of gfxdrivers from directfb-udeb * Open a bug against directfb package, asking to add dfbinfo to directfb-udeb * Open a bug against rootskel-gtk, asking for inclusion of GTK Bladr theme (which i recently stripped down to ~100 KB) cheers Attilio _______________________________________________ directfb-dev mailing list [email protected] http://mail.directfb.org/cgi-bin/mailman/listinfo/directfb-dev
