On Jan 27, 2004, at 12:02 AM, Carlos Correa wrote:
> Razor123:
> =A0
> 26 January 2004: Preliminary framebuffer code in CVS=A0=20
> drivers/video/gamecube.c can clear the screen and hopefully soon=20
> display text.
> =A0
> =A0
> Nice code, but i would like to know who did it. I think it was mist=20
> but i could be wrong, also if needed i think i have some ideas on=20
> having text displayed, maybe even in color.
> also, i haven't test the kernel due to need to buy a bba and=20
> Pso(game), so would like to know what happenes up to this point, and=20=
> why some gamecubes have different problems the other from what i hear.
I can't say anything about the crashes at various points on different=20
machines.
The framebuffer code has been written by myself. Well, written is the=20
wrong term. Ripped. I used vesafb (because it seems to be the simplest=20=
and most generic driver), removed most of what deals with VESA and=20
hardcoded it to 16 bits/pixel. I know this won't produce the correct=20
result, because 16 bits means RGB 5:5:5, but we should already see=20
*something*. As soon as we do, we can finally implement the correct=20
algorithm for this colour coding.
At the moment, both tmbinc's console driver (which does not a=20
framebuffer driver, it only listens to puts() and prints that on the=20
screen using its own code) and the framebuffer driver are enabled, so=20
both should print on the screen. Unfortunately, only the console driver=20=
actually prints on the screen, but the framebuffer driver gets=20
initialized (the console driver prints a message about framebuffer=20
initialization), and the framebuffer driver also clears the screen when=20=
it gets initialized.
It may be a problem that the "framebuffer console" driver does not get=20=
used (as the console driver continues printing after framebuffer=20
initialization), but the kernel messages tell us that the kernel=20
switches the console to the framebuffer. Weird.
Michael=
|
