Hi alltogether, On Fri, Dec 02, 2005 at 10:18:40AM +0100, Attilio Fiandrotti wrote: > 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, 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 andi@fischlustig.de (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 > export DEBIAN_FRONTEND=gtk > debian-installer > > 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. I booted "install DEBIAN_FRONTEND=newt" and did as recommended above. And it worked! Well, there seems to be an endianess bug in the coloring, which you can see in the attached screenshot. I did not try to finish the installation today, perhaps I'll try next week. Thanks, Wolfi > > > > 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 > no-hardware > #lets user dumping screen by pressing "Stamp" key > screenshot-dir=/ > > 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 > into libdirectfb? > maybe this can be done next time you release DFB 0.9.24, that seems to > contain many bugfixes over DFB 0.9.22 > (http://www.directfb.org/index.php?path=Main%2FNews) ? > > > >>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. > > 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 > >>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 directfb-dev@directfb.org? 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 ? > > maybe the /etc/directfb configuration file is a better option, but i'm > not 100% sure about that. > > ciao > > Attilio
Attachment:
dfb_0000.ppm.gz
Description: Binary data
Attachment:
signature.asc
Description: Digital signature