Re: Bug#341597: [ppc,d-i-gtk] installation report on b&w G3
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 :)
> 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.
> 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 ?