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, > >that > >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 PROTECTED] (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 > > --with-gfxdrivers=none > > 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 > http://www.directfb.org/docs/directfbrc.5.html). > Since this seems to be a DFB upstream bug, shouldn't better the > discussion take place at [EMAIL PROTECTED] here we could get > more specialistic help. > To make simple tests you could compile and run the "simple" app from > http://www.directfb.org/downloads/Extras/DFBTutorials-0.5.0.tar.gz 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 ? Friendly, Sven Luther -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
