[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [directfb-dev] [g-i] Issues with directfb input devices handling

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 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)



Reply to: