From: Michael S. <st...@in...> - 2004-01-27 10:32:23
|
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= |