Menu
▾
▴
linux-fbdev-devel — linux-fbdev mailing list for project developers
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
(1) |
Apr
(104) |
May
(81) |
Jun
(248) |
Jul
(133) |
Aug
(33) |
Sep
(53) |
Oct
(82) |
Nov
(166) |
Dec
(71) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(121) |
Feb
(42) |
Mar
(39) |
Apr
(84) |
May
(87) |
Jun
(58) |
Jul
(97) |
Aug
(130) |
Sep
(32) |
Oct
(139) |
Nov
(108) |
Dec
(216) |
| 2003 |
Jan
(299) |
Feb
(136) |
Mar
(392) |
Apr
(141) |
May
(137) |
Jun
(107) |
Jul
(94) |
Aug
(262) |
Sep
(300) |
Oct
(216) |
Nov
(72) |
Dec
(94) |
| 2004 |
Jan
(174) |
Feb
(192) |
Mar
(215) |
Apr
(314) |
May
(319) |
Jun
(293) |
Jul
(205) |
Aug
(161) |
Sep
(192) |
Oct
(226) |
Nov
(308) |
Dec
(89) |
| 2005 |
Jan
(127) |
Feb
(269) |
Mar
(588) |
Apr
(106) |
May
(77) |
Jun
(77) |
Jul
(161) |
Aug
(239) |
Sep
(86) |
Oct
(112) |
Nov
(153) |
Dec
(145) |
| 2006 |
Jan
(87) |
Feb
(57) |
Mar
(129) |
Apr
(109) |
May
(102) |
Jun
(232) |
Jul
(97) |
Aug
(69) |
Sep
(67) |
Oct
(69) |
Nov
(214) |
Dec
(82) |
| 2007 |
Jan
(133) |
Feb
(307) |
Mar
(121) |
Apr
(171) |
May
(229) |
Jun
(156) |
Jul
(185) |
Aug
(160) |
Sep
(122) |
Oct
(130) |
Nov
(78) |
Dec
(27) |
| 2008 |
Jan
(105) |
Feb
(137) |
Mar
(146) |
Apr
(148) |
May
(239) |
Jun
(208) |
Jul
(157) |
Aug
(244) |
Sep
(119) |
Oct
(125) |
Nov
(189) |
Dec
(225) |
| 2009 |
Jan
(157) |
Feb
(139) |
Mar
(106) |
Apr
(130) |
May
(246) |
Jun
(189) |
Jul
(128) |
Aug
(127) |
Sep
(88) |
Oct
(86) |
Nov
(216) |
Dec
(9) |
| 2010 |
Jan
(5) |
Feb
|
Mar
(11) |
Apr
(31) |
May
(3) |
Jun
|
Jul
(7) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
|
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: James S. <jsi...@tr...> - 2001-06-21 21:08:10
|
> Romain Dolbeau wrote: > > > pm3fb use fbgen. I'll port as soon as it's possible (I need a ppc- > > compatible 2.4.5+ kernel before being able to test it). I can > > BenH just updated his tree to 2.4.6pre3 > > Unfortunately Ruby won't work, there's structural change in > linux/rch/ppc/boot (everything in subdirectory) and the Ruby > Makefile barf... (sigh) > > So Ruby+ppc+pm3 will have to wait a bit more :-( The patch I have at my web site should work. As for ruby against ppc I haven't had the change to sync it up. Especially since the ppc tree is one of the most complex trees. I'm just getting around to having it work with the arm tree. |
|
From: David T E. <dt...@us...> - 2001-06-21 16:16:36
|
I've got a video controller that can generate an interrupt when it's not refreshing the screen, so as to give the applications a chance to redraw without flicker. What's the interface for this sort of thing. I see several #defines for FB_SYNC_*, but I'm not sure how to use them. I would think, send the process a signal, but that may be to slow. Any good solutions? What's current status quo? -David Eger |
|
From: Romain D. <do...@ir...> - 2001-06-21 15:29:42
|
Hello, I've added a few useful IOCTL to pm3fb, and I just noticed there was a numbering convention... What letter and sequence number should I use ? It seems the letter 'F' is fo FrameBuffer, but maybe only for non-driver-specific IOCTL. aty128fb in 2.4.6pre3 use '@', and no other FB driver use the IOCTL-building macro. TIA -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Romain D. <do...@ir...> - 2001-06-21 15:11:16
|
Romain Dolbeau wrote: > pm3fb use fbgen. I'll port as soon as it's possible (I need a ppc- > compatible 2.4.5+ kernel before being able to test it). I can BenH just updated his tree to 2.4.6pre3 Unfortunately Ruby won't work, there's structural change in linux/rch/ppc/boot (everything in subdirectory) and the Ruby Makefile barf... (sigh) So Ruby+ppc+pm3 will have to wait a bit more :-( -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Geert U. <ge...@li...> - 2001-06-20 21:01:32
|
On Wed, 20 Jun 2001, David T Eger wrote:
> I'm currently implementing xxx_decode_var(). My assumptions (correct me if
> I am wrong!) are that the par and info fields have been filled out. I find
> it sort of curious that the VISUAL type is in info and not var. Is it
> expected that you cannot change the VISUAL setting (that is truecolor vs
> palettized) at runtime?
The visual is in fix because it cannot be set explicitly by an application. But
it can change, depending on the settings of var.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@li...
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
|
|
From: David T E. <dt...@us...> - 2001-06-20 20:09:18
|
I'm currently implementing xxx_decode_var(). My assumptions (correct me if I am wrong!) are that the par and info fields have been filled out. I find it sort of curious that the VISUAL type is in info and not var. Is it expected that you cannot change the VISUAL setting (that is truecolor vs palettized) at runtime? -David Eger |
|
From: Romain D. <do...@ir...> - 2001-06-20 07:27:16
|
James Simmons wrote: > I have a patch that provides a wrapper for the new api avaliable for > download. http://www.transvirtual.com/~jsimmons/newapi.diff.gz. It is > quite big. Pretty much it has a second generation of fbgen. Actually I was > thinking was if we could actually change fbgen gradually over ot the new > api this would be a better approach. I need to work with the people how > wrote fbdev using fbgen. So please step forward. I understand this wrapper allow a Runy-ified driver to be used under k2ernel 2.4 ? THat would be cool. pm3fb use fbgen. I'll port as soon as it's possible (I need a ppc- compatible 2.4.5+ kernel before being able to test it). I can add testing of this wrapper on my TODO list... -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: James S. <jsi...@tr...> - 2001-06-19 23:21:31
|
> I have 800x600 fbdev, with the default fonts. i guess that makes it
> more than 80x30, not sure thogh.
100 cols x 37 rows
> It more seems to be like the only partwith garbage is the original vga handled
> stuff, and not the other way around.
>
> (note there where problems with vga fontmap getting corrupted when launching
> X, so there may be some problem with the vga text mode handling of the board,
> maybe due to the gamma chip being used as bridge to the agp bus. we solved it
> by hand saving the fontmap memory, and not using the vga functions of X).
Hum. Try this patch and let me know if it works.
diff -urN vgacon.c.orig vgacon.c
--- vgacon.c.orig Tue Jun 19 16:16:32 2001
+++ vgacon.c Tue Jun 19 16:19:22 2001
@@ -359,6 +359,8 @@
c->vc_visible_origin = vga_vram_base;
vga_set_mem_top(c);
con_free_unimap(c->vc_num);
+ if (!vga_is_gfx)
+ scr_memsetw((void *)vga_vram_base,
+ c->vc_video_erase_char, c->vc_screenbuf_size);
}
c->vc_uni_pagedir_loc = &c->vc_uni_pagedir;
con_set_default_unimap(c->vc_num);
|
|
From: James S. <jsi...@tr...> - 2001-06-19 23:15:01
|
> x86 hardware just plain [censored]. Amen!!! In the next few years you will see vga text mode go away now that 1) VESA graphics modes exist across many PC cards so a BIOS can use those modes instead. 2) DOS is offically dead. |
|
From: Paul M. <pm...@mv...> - 2001-06-19 22:59:11
|
On Tue, Jun 19, 2001 at 03:51:49PM -0700, James Simmons wrote: > Another item to discuss is power management. Right now we have basically > a blanking function. I know several people have discussed wanting a api to > handling things like frontlights and backlights. Please post what is > needed so we can define something useful to everyone.=20 >=20 Suspend and resume for starters.. at least as far as LCD controllers are concerned.. Regards, --=20 Paul Mundt <pm...@mv...> MontaVista Software, Inc. |
|
From: James S. <jsi...@tr...> - 2001-06-19 22:51:58
|
Howdy!!! Another item to discuss is power management. Right now we have basically a blanking function. I know several people have discussed wanting a api to handling things like frontlights and backlights. Please post what is needed so we can define something useful to everyone. |
|
From: Sven L. <lu...@dp...> - 2001-06-19 20:52:04
|
On Tue, Jun 19, 2001 at 06:31:50PM +0200, Romain Dolbeau wrote: > Petr Vandrovec wrote: > > > So you should not have garbage problem on your machine. > > I dont, but Sven Luther is plagued with a x86 box :-) > > > Then you cannot take over vgacon... > > So, in theory, neither do pm2fb and skeletonfb ? Err, pm3bf is taking over vgacon, no proble with that apart with the garbage i see. When i find time for it i may be looking into the vga stuff petr suggested, but vga is black magic for me, and i am only saddled with such hardware because my powerpc amiga kind of died on me piece by piece. Friendly, ... Sven Luther |
|
From: Sven L. <lu...@dp...> - 2001-06-19 20:37:35
|
On Tue, Jun 19, 2001 at 10:03:09AM -0700, James Simmons wrote: > > > BTW, any idea about the 'initial garbage when using pm3fb' problem ? > > You are going from VGA to fbcon right. Size of vgacon is 80x25. What size > do you have for fbcon, 80x30? You have five extra lines which end up not > getting cleared when that buffer is allocated when take_over_console is > called. Strange, I never seen vc_resize broken before. > No, that could not be it. I have 800x600 fbdev, with the default fonts. i guess that makes it more than 80x30, not sure thogh. That said, what i see is a rectangular zone that covers almost all of the left upper part of the screen, where i see alternating bands of green columns with 1 char in them per line, and one black column without anything in it. The bands cover around 3/4 of the screen in the vertical direction, starting from the top, maybe even all ofgf it, since the log output is scrolling it up. Also it don't quite reach all the way to the right of the screen. It more seems to be like the only partwith garbage is the original vga handled stuff, and not the other way around. (note there where problems with vga fontmap getting corrupted when launching X, so there may be some problem with the vga text mode handling of the board, maybe due to the gamma chip being used as bridge to the agp bus. we solved it by hand saving the fontmap memory, and not using the vga functions of X). Friendly, Sven Luther |
|
From: <dol...@cl...> - 2001-06-19 19:43:53
|
> > Given I understand almost nothing in those bits, I assume it's > > the VGA cruft I don't want to understand :-) > > Correct! But you should understand how VGA works. How you can > program text mode without VGA knowledge?! I can't, which is fine because I don't want to :-) That's the point of fbdev + fbcon: use modern hardware at what they are best, full graphic mode (with fbdev), then add a layer (fbcon) to allow emulation of a text console. #pragma rant on Keeping old cruft like VGA text mode in modern hardware is one of the reason I despise x86 boxes. Supporting _old_ hardware is fine with me (I would have a hard time saying otherwise, given the pile of old junk lying around :-), but designing _modern_ hardware with old useless junk like text mode is really, really dumb IMHO. OpenFirmware works just fine with purely graphical head, and is a lot more powerful that the old crappy junk (I love that word, junk :-) that is the BIOS, and also works on purely non-graphical head like serial port, possibly avoiding the need for a graphic head on server. And it's the same on both Apple and Sun hardware, and other. x86 hardware just plain [censored]. #pragma rant reset -- Romain DOLBEAU ENS Cachan / Ker Lann Thesard IRISA / CAPS dol...@cl... |
|
From: James S. <jsi...@tr...> - 2001-06-19 19:24:43
|
Hi! I have a patch that provides a wrapper for the new api avaliable for download. http://www.transvirtual.com/~jsimmons/newapi.diff.gz. It is quite big. Pretty much it has a second generation of fbgen. Actually I was thinking was if we could actually change fbgen gradually over ot the new api this would be a better approach. I need to work with the people how wrote fbdev using fbgen. So please step forward. |
|
From: James S. <jsi...@tr...> - 2001-06-19 18:28:46
|
> Look at matroxfb's use of currcon = -1 && currcon = -2 ;-) If you set > currcon to -1 and invoke set_var with currcon == -2, then, if your _set_var > is correct, disp structure will get initialized, but you'll not touch > hardware, as background VT resolution just changed. Of course if you > are in ruby tree, you are lost... Well the design goals are a bit different for 2.5.X. First you can run fbdev with fbcon. This makes for a very different handling. Another thing I have done is when you insmod a fbdev driver it doesn't change the video. It leaves the hardware as is. Its when you open /dev/fb and do a FBIOPUT_VSCREENINFO the video mode really changes. So if your hardware is a vga state then you could save the state in fb_open. This is actually very nice since not all video cards have a vga state so fb_open being a optional function is perfect for this. Then for fb_close you can set the state back to vga text mode. > No, vc_resize has completely different symptoms. vgacon problem > symptoms are either completely white screen (if driver disabled > VGA apperture), or complete garbage (if driver changed VGA layout). Hum. I guess the tdfx driver handles this correctly already. |
|
From: Petr V. <VAN...@vc...> - 2001-06-19 17:21:35
|
On 19 Jun 01 at 10:09, James Simmons wrote:
>
> > I'm far off the mark :-) I've ripped-off pm2fb for pm3fb, so
> > there's _set_var before the register_frambuffer. That's
> > also the way it's done in skeletonfb...
>
> _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.
Look at matroxfb's use of currcon = -1 && currcon = -2 ;-) If you set
currcon to -1 and invoke set_var with currcon == -2, then, if your _set_var
is correct, disp structure will get initialized, but you'll not touch
hardware, as background VT resolution just changed. Of course if you
are in ruby tree, you are lost...
> > So, is there any way to prevent vgacon to try to force is
> > way inside the memory that rightfully belong to pm3fb ? :-)
> > That way, there would be neither previous content nor
> > garbage...
>
> Has nothing to do with vgacon. I bet it is vc_resize that is having
> problems.
No, vc_resize has completely different symptoms. vgacon problem
symptoms are either completely white screen (if driver disabled
VGA apperture), or complete garbage (if driver changed VGA layout).
> How Do I know this. Because I rewrote vc_resize for ruby and
> I had these same problem until I fixed them. Plus most PC cards are
> designed to startup in vga text mode. Unless you flash the card bios, if
> possible, you are stuck with it.
I do not have troubles with vc_resize if I do not print messages from
xxxxfb_set_var... Removing 'Console: XXxYY....' from console.c also
helps a bit.
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: James S. <jsi...@tr...> - 2001-06-19 17:09:52
|
> I'm far off the mark :-) I've ripped-off pm2fb for pm3fb, so > there's _set_var before the register_frambuffer. That's > also the way it's done in skeletonfb... _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, is there any way to prevent vgacon to try to force is > way inside the memory that rightfully belong to pm3fb ? :-) > That way, there would be neither previous content nor > garbage... Has nothing to do with vgacon. I bet it is vc_resize that is having problems. How Do I know this. Because I rewrote vc_resize for ruby and I had these same problem until I fixed them. Plus most PC cards are designed to startup in vga text mode. Unless you flash the card bios, if possible, you are stuck with it. |
|
From: James S. <jsi...@tr...> - 2001-06-19 17:03:17
|
> BTW, any idea about the 'initial garbage when using pm3fb' problem ? You are going from VGA to fbcon right. Size of vgacon is 80x25. What size do you have for fbcon, 80x30? You have five extra lines which end up not getting cleared when that buffer is allocated when take_over_console is called. Strange, I never seen vc_resize broken before. |
|
From: James S. <jsi...@tr...> - 2001-06-19 17:00:50
|
> To make sure revc always does the correct thing, there should be a 17th entry > in the display->dispsw_data telling the invertion mask. Or even now :-) |
|
From: Ghozlane T. <gt...@pr...> - 2001-06-19 16:47:20
|
----- Original Message ----- From: "Petr Vandrovec" <VAN...@vc...> Sent: Tuesday, June 19, 2001 8:01 PM Subject: Re: [Linux-fbdev-devel] how to support almost compatible bo > Do you mean that value is now (MSB to LSB) R2[30] R1[24] R1[7:4], or is > it really R2[30] R1[7:4] R1[24] ? msb to lsb it's R1[24] R1[7:4] R2[30]. ' don't know where they get this kind of ideas ... > Anyway, easiest thing is: > [ sample code ...] > All drivers are full of such code. all right, thank you ... I had a similar solution. well. less clear , and I wasn't satisfied with what the code looked like ... ghoz |
|
From: Petr V. <VAN...@vc...> - 2001-06-19 16:46:21
|
On 19 Jun 01 at 18:31, Romain Dolbeau wrote:
> Petr Vandrovec wrote:
>
> > So you should not have garbage problem on your machine.
>
> I dont, but Sven Luther is plagued with a x86 box :-)
So he has to write patch. It should not be too hard, as VGA
registers are readable...
> > Then you cannot take over vgacon...
>
> So, in theory, neither do pm2fb and skeletonfb ?
Yes.
> I think then that skeletonfb should be flagged as such,
> and all hardware driver that are non-VGA aware also.
> (if it's already documented somewhere, apology,
> I'm used to ignore everything that's labelled VGA :-)
matroxfb can take over vgacon. But I do not think that matroxfb
is best candidate for skeletonfb...
> I haven't ever used any of this stuff, so I guess it's
> really (supposed to be) handled by fbgen or fbcon...
As long as vgacon will store its data directly in videomemory,
there is no way to go - your driver must take a care, as you can
use printk() in this portition of driver, and printk can modify
videomemory...
> > It is much better just restore GDC/SEQ/CRTC state (you need
> > to restore only registers needed for proper reading characters
> > from videoram, ~10 registers) to their values on enter to your
> > driver just before you do call to register_framebuffer().
>
> Given I understand almost nothing in those bits, I assume it's
> the VGA cruft I don't want to understand :-)
Correct! But you should understand how VGA works. How you can
program text mode without VGA knowledge?!
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Romain D. <do...@ir...> - 2001-06-19 16:31:54
|
Petr Vandrovec wrote: > So you should not have garbage problem on your machine. I dont, but Sven Luther is plagued with a x86 box :-) > Then you cannot take over vgacon... So, in theory, neither do pm2fb and skeletonfb ? I think then that skeletonfb should be flagged as such, and all hardware driver that are non-VGA aware also. (if it's already documented somewhere, apology, I'm used to ignore everything that's labelled VGA :-) > Only thing you can do is read read first and last console from > video=vc: kernel parameter, and then at the beginning of your > code you can call con_save_screen for all these terminals you > are taking over. Then replace console's con_save_screen handler > with NULL. But it is very dangerous, incompatible and so on... I haven't ever used any of this stuff, so I guess it's really (supposed to be) handled by fbgen or fbcon... > It is much better just restore GDC/SEQ/CRTC state (you need > to restore only registers needed for proper reading characters > from videoram, ~10 registers) to their values on enter to your > driver just before you do call to register_framebuffer(). Given I understand almost nothing in those bits, I assume it's the VGA cruft I don't want to understand :-) -- DOLBEAU Romain | l'histoire est entierement vraie, puisque ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre do...@ir... | -- Boris Vian |
|
From: Petr V. <VAN...@vc...> - 2001-06-19 16:22:08
|
On 19 Jun 01 at 18:09, Romain Dolbeau wrote:
> Petr Vandrovec wrote:
> > And this is what? Do you mean that vgacon -> pm3fb switch during
> > bootup does not preserve contents of screen? Make sure that
> > on enter to register_framebuffer() pm3fb is in VGA mode, memory
> > is mapped at 0xB8000 and SEQ/GDC/CRTC are set for VGA text mode.
>
> It definitely isn't. I don't even know what VGA mode is, and I
> have absolutely no intention to ever learn. VGA is one of the
> crappy thing that keep me away from x86 hardware.
So you should not have garbage problem on your machine.
> > and all code which changes memory layout and enables/disables VGA emulation
> > should be executed only from inside yourfb_set_var and not before
> > call to register_framebuffer.
>
> I'm far off the mark :-) I've ripped-off pm2fb for pm3fb, so
> there's _set_var before the register_frambuffer. That's
> also the way it's done in skeletonfb...
Then you cannot take over vgacon...
> Also, pm3fb depend on fbgen, which supplies the _set_var
> and _get_var, and currcon. I have no control over those.
>
> So, is there any way to prevent vgacon to try to force is
> way inside the memory that rightfully belong to pm3fb ? :-)
> That way, there would be neither previous content nor
> garbage...
Only thing you can do is read read first and last console from
video=vc: kernel parameter, and then at the beginning of your
code you can call con_save_screen for all these terminals you
are taking over. Then replace console's con_save_screen handler
with NULL. But it is very dangerous, incompatible and so on...
It is much better just restore GDC/SEQ/CRTC state (you need
to restore only registers needed for proper reading characters
from videoram, ~10 registers) to their values on enter to your
driver just before you do call to register_framebuffer().
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Romain D. <do...@ir...> - 2001-06-19 16:09:52
|
Petr Vandrovec wrote:
> And this is what? Do you mean that vgacon -> pm3fb switch during
> bootup does not preserve contents of screen? Make sure that
> on enter to register_framebuffer() pm3fb is in VGA mode, memory
> is mapped at 0xB8000 and SEQ/GDC/CRTC are set for VGA text mode.
It definitely isn't. I don't even know what VGA mode is, and I
have absolutely no intention to ever learn. VGA is one of the
crappy thing that keep me away from x86 hardware.
I'll add proper code to do the proper thing, if someone write
it, but don't ask me to _understand_ that code :-)
> During register_framebuffer() vgacon reads VGA videoram, then
> _set_var (I believe that implicitly through your console_switch) of
> your framebuffer is invoked, and screen is repainted using putcs...
>
> So you should have some currcon variable in your fbinfo:
>
> fbinfo.currcon = -1;
> register_framebuffer(&fbinfo);
> if (fbinfo.currcon == -1) {
> /* we are second head... */
> yourfb_set_var(.....);
> }
>
> and your fbinfo_select_console should do:
>
> fbinfo.currcon = new_console;
> yourfb_set_var(.....);
>
> and all code which changes memory layout and enables/disables VGA emulation
> should be executed only from inside yourfb_set_var and not before
> call to register_framebuffer.
I'm far off the mark :-) I've ripped-off pm2fb for pm3fb, so
there's _set_var before the register_frambuffer. That's
also the way it's done in skeletonfb...
Also, pm3fb depend on fbgen, which supplies the _set_var
and _get_var, and currcon. I have no control over those.
So, is there any way to prevent vgacon to try to force is
way inside the memory that rightfully belong to pm3fb ? :-)
That way, there would be neither previous content nor
garbage...
--
DOLBEAU Romain | l'histoire est entierement vraie, puisque
ENS Cachan / Ker Lann | je l'ai imaginee d'un bout a l'autre
do...@ir... | -- Boris Vian
|
754 messages has been excluded from this view by a project administrator.
