|
From: James S. <jsi...@tr...> - 2002-04-30 18:12:16
|
> > the reason was discovered to be from calling set_var before > > register_framebuffer. > > Not sure about this one, because applying the patch from roman to 2.4.18 + > pm3fb did hang the kernel early one (before registering the fbdev i think, it > never switched away from the console text mode). That said, i don't get a > white space stuff, but a green/black vertical stripes with some char embedded > in the green ones. I couldn't do the patch over night. Not with the current fbdev system. The approach will be to migrate all fbdev drivers over to the new api. Then the stuff in fbgen.c can be intergrated into fbcon.c. See fbgen.c has its own generic switch_con function. Once every driver uses that it will be easier to change one function then many functions. > > Hm. The console system should be handling restoring the fonts. Unfortunely > > it doesn't. I can see this when I use the vesa framebuffer and X. > > Yes, it did not work for. The problem for X was that the vga mmio interface of > the chip was broken, so we copy the data by hand. Yuck!! > I would do the same for pm3fb, but i don't know where the char data is held in > the vga memory (which is part of the framebuffer memory, i think), and copying > all 64K of it like is done in the X driver would not help us. Hm. I have to think about that one. |