Re: Bug#341597: [ppc,d-i-gtk] installation report on b&w G3
Sven Luther wrote:
On Thu, Dec 01, 2005 at 09:46:50PM +0100, Attilio Fiandrotti wrote:
Mmm, this is a rage 128, not sure if it will have enough memory, or if the
corresponding fbdev is broken or something.
Attilio, do you perhaps have some program linked with the .deb libraries,
the user could run to test under normal circunstances ? This would make
debugging somewhat easier maybe.
this is what i got on directfb-dev from email@example.com (thanks!)
after forwarding wolfram's post
I recommend to disable hw acceleration on ppc systems. At least for now.
Oh well, we should fix it instead, whatever it is :)
Wolfram, could you please try again to boot with newt fontend and, after
switching to VT2, do
echo 'debug' >>/etc/directfbrc
echo 'no-hardware' >/etc/directfbrc
echo 'screenshot-dir=/' >>/etc/directfbrc
this should let us know if the bug goes away if hw aceleration is
disabled, and you can also take screenshots by pressing "stamp" key.
If the bug is fixed when hw-acceleration is disabled i think a good idea
would be making the libdirectfb or the gtk-rootskel udeb containing anto
/etc/directfbrc configuration file that contains
#prevents DFB from using hardware acceleration
#lets user dumping screen by pressing "Stamp" key
this would faclitate taking screenshots of the g-i and could prevent
some issues related to hw-aceleration.
Guillem, as maintainer of libdirectfb where do you think is better
placing the /etc/directfb configuration file? into the gtk-rootskel or
maybe this can be done next time you release DFB 0.9.24, that seems to
contain many bugfixes over DFB 0.9.22
It is best to pass
to configure on ppc.
Judging from your cursor you are experiencing the "bi-endian system"
problem. (ram: big-endian, vram: little-endian). This should not result
I have some problem understanding this, back in the days when i used to write
X graphic drivers (for 3dlabs permedia3 and later wildcat vp), i remember
perfectly the graphic card being able to be programmed in auto endian
switching when accessing the video ram, and i suppose that is what X does. I
think there is no reason this should not happen here, and i even believe this
is the way the fbdev drivers program it, since it usually is part of the
low-level programmation of the video ram aperture, not something which would
need to be done in the directfb accel driver.
Sven, if you could ask for more details on this on directfb-dev it would
be very useful for the g-i.
in a crash, but shows me that you are using a gfxdriver, which in
addidion may cause your segfault.
i know HW acceleration can disabled at runtime bi adding "no-hardware"
option to /etc/directfb (see
Since this seems to be a DFB upstream bug, shouldn't better the
discussion take place at firstname.lastname@example.org? here we could get
more specialistic help.
To make simple tests you could compile and run the "simple" app from
Well, if we can disable it at runtime, the best is to have a d-i kernel
command line option to disable it or something, no ?
maybe the /etc/directfb configuration file is a better option, but i'm
not 100% sure about that.