From: Jim H. <jim...@ac...> - 2002-04-24 21:44:23
|
I've been using the Permedia2 driver on x86 for some time. I've always built the kernel with the VGA console and the pm2 driver built in. So booting begins through the VGA console, and when the pm2 driver is loaded it grabs the console, up goes Tux and on we go. As you might expect. Except what actually happens is that most of the screen is cleared to white, and console messages appear on the bottom line of the white area. As the console scrolls the white area scrolls up the screen, though that part of it to the right of Tux remains as long as Tux remains. The size of the white area is the size of the VGA screen, both considered in terms of character positions. So with regular VGA it is 80x25. I tend to use 80x50 VGA, hence 'most' of the screen, my fb console size being 144x56. For ages I thought this was a problem with the Permedia2 driver, and so have been giving myself an introduction to the console code digging around trying to find the problem. I haven't got to the bottom of it, but it looks to me like the problem is not a Permedia2 driver one, and that users of other drivers should see it to. Is this true? Is this an old chestnut that is well understood and has been done to death on the list in the past? As far as I can tell at the moment, in take_over_console the outgoing console is suppose to save its screen contents (if visible) and these will be put onto the new console when update_screen() is called. Dumping the saved VGA screen, it seems that the saved screen consists entirely of 0x720, which I think explains the white. Why the VGA screen contents are like that I have, as yet, no idea. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
From: James S. <jsi...@tr...> - 2002-04-24 22:32:04
|
> I've been using the Permedia2 driver on x86 for some time. I've always built > the kernel with the VGA console and the pm2 driver built in. > > So booting begins through the VGA console, and when the pm2 driver is loaded it > grabs the console, up goes Tux and on we go. As you might expect. > Except what actually happens is that most of the screen is cleared to white, > and console messages appear on the bottom line of the white area. As the > console scrolls the white area scrolls up the screen, though that part of it to > the right of Tux remains as long as Tux remains. > > The size of the white area is the size of the VGA screen, both considered in > terms of character positions. So with regular VGA it is 80x25. I tend to use > 80x50 VGA, hence 'most' of the screen, my fb console size being 144x56. > > For ages I thought this was a problem with the Permedia2 driver, and so have > been giving myself an introduction to the console code digging around trying to > find the problem. I haven't got to the bottom of it, but it looks to me like > the problem is not a Permedia2 driver one, and that users of other drivers > should see it to. > > Is this true? Is this an old chestnut that is well understood and has been done > to death on the list in the past? > > As far as I can tell at the moment, in take_over_console the outgoing console > is suppose to save its screen contents (if visible) and these will be put onto > the new console when update_screen() is called. Dumping the saved VGA screen, > it seems that the saved screen consists entirely of 0x720, which I think > explains the white. Why the VGA screen contents are like that I have, as yet, no > idea. I figured the problem was with the core console code. You found the bug that I have seen before in other drivers. Dave Jones reported to me for the 3dfx driver. I never had this problem but he did. Now we know what causes it. I to have no idea why the VGA screen contents are like that either. |
From: Jani M. <ja...@iv...> - 2002-04-26 06:01:28
|
I had this problem with the trident driver and the problem went away if I did not set_var() before register_framebuffer.This was suggested by Antonio Daplas on this list .So I think the video mode should not be set until the fb is registered. > > The size of the white area is the size of the VGA screen, both considered in > terms of character positions. So with regular VGA it is 80x25. I tend to use > 80x50 VGA, hence 'most' of the screen, my fb console size being 144x56. |
From: James S. <jsi...@tr...> - 2002-04-30 17:14:32
|
> I had this problem with the trident driver and the problem went away if > I did not set_var() before register_framebuffer.This was suggested by > Antonio Daplas on this list .So I think the video mode should not be set > until the fb is registered. I agree. In fact I like to see the set_var stuff moved into fbcon.c. It can be done since I already have done it. |
From: Sven <lu...@dp...> - 2002-04-29 10:31:56
|
On Wed, Apr 24, 2002 at 10:44:18PM +0100, Jim Hague wrote: > I've been using the Permedia2 driver on x86 for some time. I've always built > the kernel with the VGA console and the pm2 driver built in. > > So booting begins through the VGA console, and when the pm2 driver is loaded it > grabs the console, up goes Tux and on we go. As you might expect. > Except what actually happens is that most of the screen is cleared to white, > and console messages appear on the bottom line of the white area. As the > console scrolls the white area scrolls up the screen, though that part of it to > the right of Tux remains as long as Tux remains. I have the same problem with pm3fb. From previous discution here, the culprit seems to be that the part of the fbdev drvier responsible for getting the VGA text data and writing it to the fbdev console is broken. If you have any fix to this, i would be very interested in it, to try to duplicate it in pm3fb also. > The size of the white area is the size of the VGA screen, both considered in > terms of character positions. So with regular VGA it is 80x25. I tend to use > 80x50 VGA, hence 'most' of the screen, my fb console size being 144x56. > > For ages I thought this was a problem with the Permedia2 driver, and so have > been giving myself an introduction to the console code digging around trying to > find the problem. I haven't got to the bottom of it, but it looks to me like > the problem is not a Permedia2 driver one, and that users of other drivers > should see it to. The difference is most probably that this is not broken for other drivers. Maybe the main reason of this, is that both pm2fb and pm3fb were first developped on plateforms without vga text console. > Is this true? Is this an old chestnut that is well understood and has been done > to death on the list in the past? I think it is a known but unfixed problem, see previous posts about pm3fb on this problem, especially responces to me by Petr with some vga black magic in it. > As far as I can tell at the moment, in take_over_console the outgoing console > is suppose to save its screen contents (if visible) and these will be put onto > the new console when update_screen() is called. Dumping the saved VGA screen, > it seems that the saved screen consists entirely of 0x720, which I think > explains the white. Why the VGA screen contents are like that I have, as yet, no > idea. But the traditional way of doing it may be broken on pm2fb. i don't know, but while writing the pm3 X driver, i noticed that may board will not save/restore the fonts correctly when doing MMIO (and when not doing MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane actually) did change the code to read/save font memory using a special memcopy instead of resorting to the vga interface, which seemed broken in this respect. Maybe the pm2 chip shares this problem ? BTW, what exact pm2 chip are you using ? Friendly, Sven Luther |
From: Jim H. <jim...@ac...> - 2002-04-29 11:06:41
|
On 29-Apr-2002 Sven wrote: >> Except what actually happens is that most of the screen is cleared to white, >> and console messages appear on the bottom line of the white area. As the >> console scrolls the white area scrolls up the screen, though that part of it >> to >> the right of Tux remains as long as Tux remains. > > I have the same problem with pm3fb. Good. I have also had reports of this with a couple of other framebuffers, e.g. Jani Monoses's tridentfb experience. So I don't think it is a problem with the pm2/3 drivers. I've not had much time to look further into this, but I think there are actually two things going wrong. I need to find some more time. Here's what it looks like to me at the moment. First, in take_over_console(), save_screen() is called before the old console is deinit()'ed. This calls vgacon_save_screen() to copy the console contents at vc_origin into vc_screenbuf. Something is weird for me here; a little dumping shows that vc_screenbuf always ends up filled with 0xffff. Then take_over_console() closes the VGA console and calls visual_init() on the FB console, which in turn calls fbcon_init() and fbcon_setup(). During fbcon_setup(), the size of the new console is noted as being different from the old console, and vc_resize() is called. This creates a new vc_screenbuf, and fills it with data from the old size, taken from vc_origin. I think, though I'm not sure, that at this point vc_origin is not yet updated for the FB and still is the VGA origin. This data copied from vc_origin is again always 0xffff for me. So now I think I need to understand *why* the data at vc_origin for the VGA console appears to be completely wrong. > The difference is most probably that this is not broken for other drivers. > Maybe the main reason of this, is that both pm2fb and pm3fb were first > developped on plateforms without vga text console. I suspect that all/most FB drivers (I think Jani works round it with tridentfb) will show this problem. But to see it you need to be switching from a VGA console to a FB console - if I remove the VGA console from my kernel everything looks fine - so this problem will only practically be seen on PCs. And there are not many reasons to use FB on a PC. > i don't know, but while writing the pm3 X driver, i noticed that may board > will not save/restore the fonts correctly when doing MMIO (and when not doing > MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane > actually) did change the code to read/save font memory using a special > memcopy instead of resorting to the vga interface, which seemed broken in > this respect. Maybe the pm2 chip shares this problem ? That's interesting. I will compare your code to pm2fb. > BTW, what exact pm2 chip are you using ? My PCI reports TVP4020. I have no documentation on the chip anyway, so I don't know how it is supposed to work... -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift. |
From: Jani M. <ja...@iv...> - 2002-04-29 12:23:38
|
The way it disappeared for me was by not calling do_set_var in trident init.It was called before register_frambuffer.I thought I posted to the list last week but it seems I only replied to Jim. Antonio Daplas suggested that the card should not be in graphics mode when registering the fb.See the list archives subject: tridentfb review some months ago) > I suspect that all/most FB drivers (I think Jani works round it with > tridentfb) will show this problem. But to see it you need to be switching from > a VGA console to a FB console - if I remove the VGA console from my kernel > everything looks fine - so this problem will only practically be seen on PCs. > And there are not many reasons to use FB on a PC. |
From: Jim H. <jim...@ac...> - 2002-04-30 09:20:29
|
On 29-Apr-2002 Jani Monoses wrote: > The way it disappeared for me was by not calling do_set_var in trident > init.It was called before register_frambuffer.I thought I posted to the > list last week but it seems I only replied to Jim. > Antonio Daplas suggested that the card should not be in graphics mode when > registering the fb.See the list archives subject: tridentfb review some > months ago) Jani, thank you. I get what you are saying, now. Sorry it took me so long to catch on. BTW, I can't find the 'tridentfb review' thread in the archives. The problem is, essentially, that the outgoing VGA console and the incoming FB console are the same card. Initialise that card to a graphics mode and *blam* the card remaps to the graphics mode and fishing around in the text mode screen memory to find the contents of the outgoing console produces random garbage. So Antonio's suggestion that the card should not be in graphics mode when registering the FB is correct; registering needs to happen before the card is switched away from VGA mode in any way. Simply removing the call to do_set_var doesn't work for pm2fb; I think too much initialisation has happened by then. Sven, pmfb is (I think) similar in this respect; any ideas? -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
From: Jani M. <ja...@iv...> - 2002-04-30 09:32:43
|
On Tue, 30 Apr 2002, Jim Hague wrote: > catch on. BTW, I can't find the 'tridentfb review' thread in the archives. ok I didn't remember the subject ---------- Forwarded message ---------- Date: 28 Nov 2001 10:53:46 +0800 From: Antonino Daplas <ad...@po...> To: Jani Monoses <ja...@as...> Subject: Re: [Linux-fbdev-devel] driver review please :) (beware,size = 30K) On Tue, 2001-11-27 at 22:14, Jani Monoses wrote: > > * when I insmod it the console is cleared with white(maybe that's OK > I haven't seen other modular fb's?) > I think that can happen if your display is already in graphics mode before you register the framebuffer. Tony |
From: Romain D. <do...@ir...> - 2002-04-30 09:33:56
Attachments:
pm3fb-VGATEST.patch
|
Jim Hague wrote: > So Antonio's suggestion that the card should not be in graphics mode when > registering the FB is correct; registering needs to happen before the card is > switched away from VGA mode in any way. Simply removing the call to do_set_var > doesn't work for pm2fb; I think too much initialisation has happened by then. > Sven, pmfb is (I think) similar in this respect; any ideas? Well, pm3fb definitely does do a bunch of initializations before registering. The attached patch *might* solve the problem (I use a PPC box so all that VGA crap is unknown to me...) All those who see the problem, please test and report. -- DOLBEAU Romain | Long live rock and roll ENS Cachan / Ker Lann | Long live rock 'n' roll Thesard IRISA / CAPS | Long live rock and roll dol...@cl... | -- Rainbow, 'Long Live Rock 'N' Roll' |
From: Sven <lu...@dp...> - 2002-04-30 09:38:37
|
On Tue, Apr 30, 2002 at 11:33:36AM +0200, Romain Dolbeau wrote: > Jim Hague wrote: > > > So Antonio's suggestion that the card should not be in graphics mode when > > registering the FB is correct; registering needs to happen before the card is > > switched away from VGA mode in any way. Simply removing the call to do_set_var > > doesn't work for pm2fb; I think too much initialisation has happened by then. > > Sven, pmfb is (I think) similar in this respect; any ideas? > > Well, pm3fb definitely does do a bunch of initializations > before registering. The attached patch *might* solve the > problem (I use a PPC box so all that VGA crap is unknown to me...) > All those who see the problem, please test and report. Ok, i will try it (i suppose this is the 2.4.x tree, not yet thew 2.5.x ones, am i right ? Friendly, Sven Luther |
From: Romain D. <do...@ir...> - 2002-04-30 09:41:47
|
> Ok, i will try it (i suppose this is the 2.4.x tree, not yet thew 2.5.x ones, > am i right ? Either 2.4.x or the older 2.5.y w/ the older fbdev. (I assume your patch for 2.5.2 works for you :-) I tried 2.5.11, it doesn't even compile the IDE stuff on my laptop now... 2.5.y on PPC is getting worse with each new release :-( -- DOLBEAU Romain | The Gods made Heavy Metal ENS Cachan / Ker Lann | and it's never gonna die Thesard IRISA / CAPS | -- Manowar, dol...@cl... | 'The Gods made Heavy Metal' |
From: Sven <lu...@dp...> - 2002-04-30 09:44:07
|
On Tue, Apr 30, 2002 at 11:41:31AM +0200, Romain Dolbeau wrote: > > > Ok, i will try it (i suppose this is the 2.4.x tree, not yet thew 2.5.x ones, > > am i right ? > > Either 2.4.x or the older 2.5.y w/ the older fbdev. > (I assume your patch for 2.5.2 works for you :-) Yes, but i have not tried it yet, it would be better to work on 2.4.x for this now (is 2.4.19 already released ?) and try again 2.5.x once this is solved (and i have more time). > I tried 2.5.11, it doesn't even compile the IDE stuff > on my laptop now... 2.5.y on PPC is getting worse with > each new release :-( I had troubles also, but then it was before the new fbdev stuff got merged in, so i will have to test again, but i have not a lot of time. Friendly, Sven Luther |
From: Romain D. <do...@ir...> - 2002-04-30 09:46:29
|
Sven wrote: > Yes, but i have not tried it yet, it would be better to work on 2.4.x for this > now (is 2.4.19 already released ?) 2.4.19 hasn't been released yet. I'll try the patch on my box tonight. It it doesn't break anything and improves thing for you, I'll try to get it integrated to 2.4.19. -- DOLBEAU Romain | I have lost the will to live ENS Cachan / Ker Lann | Simply nothing more to give Thesard IRISA / CAPS | -- Metallica, dol...@cl... | 'Fade to Black' |
From: Sven <lu...@dp...> - 2002-04-30 17:47:06
|
On Tue, Apr 30, 2002 at 11:46:18AM +0200, Romain Dolbeau wrote: > Sven wrote: > > > Yes, but i have not tried it yet, it would be better to work on 2.4.x for this > > now (is 2.4.19 already released ?) > > 2.4.19 hasn't been released yet. I'll try the patch on > my box tonight. It it doesn't break anything and improves > thing for you, I'll try to get it integrated to 2.4.19. Nope, the patch didn't work, andeven worse, the kernel would not boot anymore with it applied. it never did the switch to pm3fb (but vesafb was fine) (and frooze juste before it). Friendly, Sven Luther |
From: James S. <jsi...@tr...> - 2002-04-30 18:08:19
|
> Either 2.4.x or the older 2.5.y w/ the older fbdev. > (I assume your patch for 2.5.2 works for you :-) I still lift hooks for the old api. At present both apis can exist at the same time. I didn't want to break every fbdev driver at one time. > I tried 2.5.11, it doesn't even compile the IDE stuff > on my laptop now... 2.5.y on PPC is getting worse with > each new release :-( The PPC stuff I can't help you with. Is this with the PPC tree as well? At present 2.5.11 is really broken. I expect 2.5.12 to be much better once all the fixes go in. |
From: James S. <jsi...@tr...> - 2002-04-30 17:59:40
|
> The problem is, essentially, that the outgoing VGA console and the incoming FB > console are the same card. Initialise that card to a graphics mode and *blam* > the card remaps to the graphics mode and fishing around in the text mode > screen memory to find the contents of the outgoing console produces random > garbage. Correct. On ix86 before you set the video hardware we are at 0xA000 in text mode. Once you change to graphics mode it is somewhere in PCI memory space, plus the data format is completely different. Then calling register_framebuffer then calls take_over_console whcih in turn calls the old video driver (vgacon) to grab the data (save_screen). Now that the hardware is in a different state the data is invalid. Then it updates the screen with the new data. > So Antonio's suggestion that the card should not be in graphics mode when > registering the FB is correct; registering needs to happen before the card is > switched away from VGA mode in any way. Simply removing the call to do_set_var > doesn't work for pm2fb; I think too much initialisation has happened by then. > Sven, pmfb is (I think) similar in this respect; any ideas? The key is to not touch the hardware at all before register_framebuffer. fbcon_init could do it instead. The problem we have to watch out for is con_switch. This is where alot of problems lie. |
From: James S. <jsi...@tr...> - 2002-04-30 17:28:18
|
I plan to move set_var in every driver into fbcon.c. . --- |o_o | |:_/ | Give Micro$oft the Bird!!!! // \ \ Use Linux!!!! (| | ) /'_ _/`\ ___)=(___/ On Mon, 29 Apr 2002, Jani Monoses wrote: > The way it disappeared for me was by not calling do_set_var in trident > init.It was called before register_frambuffer.I thought I posted to the > list last week but it seems I only replied to Jim. > Antonio Daplas suggested that the card should not be in graphics mode when > registering the fb.See the list archives subject: tridentfb review some > months ago) > > > > I suspect that all/most FB drivers (I think Jani works > round it with > > tridentfb) will show this problem. But to see it you need to be switching from > > a VGA console to a FB console - if I remove the VGA console from my kernel > > everything looks fine - so this problem will only practically be seen on PCs. > > And there are not many reasons to use FB on a PC. > > > _______________________________________________ > Linux-fbdev-devel mailing list > Lin...@li... > https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel > |
From: James S. <jsi...@tr...> - 2002-04-30 17:26:18
|
> > Except what actually happens is that most of the screen is cleared to white, > > and console messages appear on the bottom line of the white area. As the > > console scrolls the white area scrolls up the screen, though that part of it to > > the right of Tux remains as long as Tux remains. > > I have the same problem with pm3fb. the reason was discovered to be from calling set_var before register_framebuffer. > i don't know, but while writing the pm3 X driver, i noticed that may board > will not save/restore the fonts correctly when doing MMIO (and when not doing > MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane > actually) did change the code to read/save font memory using a special memcopy > instead of resorting to the vga interface, which seemed broken in this > respect. Maybe the pm2 chip shares this problem ? 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. |
From: Sven <lu...@dp...> - 2002-04-30 17:46:16
|
On Tue, Apr 30, 2002 at 10:26:08AM -0700, James Simmons wrote: > > > > Except what actually happens is that most of the screen is cleared to white, > > > and console messages appear on the bottom line of the white area. As the > > > console scrolls the white area scrolls up the screen, though that part of it to > > > the right of Tux remains as long as Tux remains. > > > > I have the same problem with pm3fb. > > 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 don't know, but while writing the pm3 X driver, i noticed that may board > > will not save/restore the fonts correctly when doing MMIO (and when not doing > > MMIO it would not work in dual pm3 configuration) so we (Well Alan Hourihane > > actually) did change the code to read/save font memory using a special memcopy > > instead of resorting to the vga interface, which seemed broken in this > > respect. Maybe the pm2 chip shares this problem ? > > 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. 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. Friendly, Sven Luther |
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. |
From: Antonino D. <ad...@po...> - 2002-04-30 18:33:39
|
On Wed, 2002-05-01 at 01:46, Sven wrote: > On Tue, Apr 30, 2002 at 10:26:08AM -0700, James Simmons wrote: > > > > > > Except what actually happens is that most of the screen is cleared to white, > > > > and console messages appear on the bottom line of the white area. As the > > > > console scrolls the white area scrolls up the screen, though that part of it to > > > > the right of Tux remains as long as Tux remains. > > > > > > I have the same problem with pm3fb. > > > > 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. > >From what I have observed, the critical point is setting up the driver just enough so everything is initialized, but reserve switching the hardware to graphics mode only during or after register_framebuffer. Some drivers do this by checking a flag which tells if the driver is in initialization stage or not. In the case of aty128fb.c, it checks if 'con' is valid or not. It has this in set_var: if (!info->fb_info.display_fg || info->fb_info.display_fg->vc_num == con) aty128_set_par(&par, info); Probably, a similar check in pm3fb_set_par might work? Tony |
From: Jim H. <jim...@ac...> - 2002-04-30 21:19:02
|
On 30-Apr-2002 Sven wrote: >> 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 found similar with pm2fb; moving the call to register_framebuffer to before mode setup caused the kernel to hang. No time in investigate further yet. -- Jim Hague - jim...@in... (Work), ji...@be... (Play) Never trust a computer you can't lift or you don't control. |
From: <dol...@cl...> - 2002-05-01 07:31:40
|
> I found similar with pm2fb; moving the call to register_framebuffer to > before mode setup caused the kernel to hang. No time in investigate > further yet. Search the archives for this mailinglist for "pm3fb questions/problesm". It was about 10 months ago. This very problem was mentioned for pm3fb. Answer by James Simmons: > _set_var must be called before register_framebuffer. Otherwise the machien > will oops. regsiter_framebuffer calls take_over_console which calls > fbcon_startup which expects a struct display disp in fb_info to be > initialized. info->disp is initalized in xxxfb_set_var. So the initializations I'm doing in pm3fb are mandatory... -- DOLBEAU Romain | You won't break me ENS Cachan / Ker Lann | You won't make me Thesard IRISA / CAPS | You won't take me dol...@cl... | -- Judas Priest, 'Blood Red Skies' |
From: James S. <jsi...@tr...> - 2002-05-02 02:52:34
|
> This very problem was mentioned for pm3fb. Answer by James Simmons: > > > _set_var must be called before register_framebuffer. Otherwise the machien > > will oops. regsiter_framebuffer calls take_over_console which calls > > fbcon_startup which expects a struct display disp in fb_info to be > > initialized. info->disp is initalized in xxxfb_set_var. > > So the initializations I'm doing in pm3fb are mandatory... Yipes!!! Its broken both ways. I know ruby fixes this and I plan to fix this soon for 2.5.X. |