Re: Bug#341597: [ppc,d-i-gtk] installation report on b&w G3
On Fri, Dec 02, 2005 at 06:18:42PM +0100, Wolfram Quester wrote:
> > > Super-cool! :)
> > > It seems here you're still running into bug
> > > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=338191
> > > and that the initial vesa mode was set to 1024x768 instead of 800x600.
> >
> > Mmm, he does see the logo endianness problem, but not the cursor problem, is
> > that right Wolfram ?
>
> Yes, that's right.
Ok, That mean we have two bugs :
1) the cursor bug, which i part of the acceleration layer, and probably mean
the acceleration stuff is not endian clean. Different graphic chips do
cursor accel differently, some use a full overlay for the cursor (like the
wildcat vp), and some use dedicated cursor logic (like the permedia3). In
general the endianness for accel functions is separate from the endianess
for image uploads, and a no-cursor-accel option would be enough here.
2) the image upload endianess issue (is this the only place we upload images
? We will probably see it also for world-map images if we go this way for
country choser). This means the image upload layer, usually just a plain
copy to video ram, is not setting the endianess conversion of the video
memory aperture correctly. Some cards might not have a endianess conversion
aperture though, and it needs to be converted by software. Testing a generic
fbdev image viewer (there is one, don't remember the name though), and then
checking if it has endianess conversion function will tell us if it is an
fbdev bug, or if it is an issue with directfb or gtk-directfb, which do
software endianess conversion while they shouldn't.
Maybe i should take out my venerable dual-permedia3/gamma card, and try running
on it, since i master perfectly how the chip works and have the full specs.
BTW, come to think of it, will we support dual-head graphical installs ? With
one head having the d-i, and the other some log or game or whatever ? We do
have mouse support, don't we ?
/me remembers the caldera install, where you got to play tetris while the
system was installing, i wonder if we will be seeing a bunch of directfb/gtk
game .udebs for this purpose in the future :)
> > > -PowerPC specific: the kernel must get passed "video=ofonly vga=788"
> > > (wolfram, could you please test with this additional kernel parameter too?)
> >
> > Well, this is only needed for powermacs who have no radeon graphics, which
> > would include all oldworld and maybe nvidia based pmacs. The vga= parameter
> > has no chance of working at all on anything but x86. to pass size paramters,
> > you specify it with something like :
> >
> > video=radeonfb:1024x768@60
>
> OK, I tried "video=radeonfb:800x600@60" but it looks like it is ignored.
Well, obviously, as you have a rage128, not a radeon card, you would need
video=atyfb:800x600 or something such. But then, if you had to use ofonly, i
am not sure, but you could try video=ofonly:800x600@60, but as i said, i don't
think it will work.
> But I think that's not totally bad. I'd guess that 1024x768 is the video
> mode which is initialized by OF, so it should be different on some
> systems and safe for the respective graphics card (and screen).
Indeed.
> > > no-hardware
> >
> > So, you will disable hardware acceleration in all cases ? What does it bring
> > you ?
>
> I think it doesn't hurt. The installer probably doesn't do anything
> where we gain much from hardware-acceleration and hardware-acceleration
> is more error prone.
It should not, it will maybe show bugs, which needs to be fixed, but nothing
major should be different between accel and no accel.
> > > screenshot-dir=/
> > >
> > > If some other PPC user has time for some testing, could he confirm the
> > > g-i still works on their computers using new kernel parameters and
> > > /etc/directfbrc options?
>
> I can try it on my 12" PB if I have time.
Ah, that would be helpful, thanks.
> > See above for a detail about the kernel parameters, i have no time to test the
> > options though.
> >
> > > I would also know from DFB experts if there is a /etc/directfb option
> > > that prevents multibyte-colour PNGs from being trashes as seen in
> > > Wolfram's screenshot (this seems to be an endianess-related issue).
See above analysis.
Friendly,
Sven Luther
Reply to: