Menu
▾
▴
linux-fbdev-devel
|
From: Petr V. <VAN...@vc...> - 2001-06-19 12:08:45
|
On 19 Jun 01 at 13:41, Sven LUTHER wrote:
> On Tue, Jun 19, 2001 at 01:34:43PM +0200, Romain Dolbeau wrote:
> > Sven LUTHER wrote:
> > pm2fb use non-accelerated fbcon-cfb8, and this one
> > simply do pixels = (pixels ^ 0x0f0f0f0f).
> >
> > So I guess it is the answer :-)
>
> Ok, let's go for this, in wait for a response from the more knowledgeable
> fbdev gurus ...
I do not know whether I'm more knowledgeable, but revc, together with
other character based functions (putc/putcs/clear (and maybe clear_margin))
have to support only 16 colors. And it is driver bussiness how it will
perform console color -> value in framebuffer mapping. But it is convient,
and couple of apps expects that for pseudocolor console color is directly
stored in framebuffer, so only palette entries 0 .. 15 are used. But
you can use entries 0, 17, 34, 51, 68, ... 238, 255 as well - although
I'm sure that some fbdev apps will not agree with you.
If you decide to use standard way, then using 0xffffffff is correct
for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for
8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor,
0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot
use RGB332 truecolor without information loss.
Petr
(*) it is (15 << red.shift) | (15 << green.shift) | (15 << blue.shift)
|
|
From: Petr V. <VAN...@vc...> - 2001-06-19 15:55:29
|
On 19 Jun 01 at 16:48, Sven LUTHER wrote:
>
> BTW, any idea about the 'initial garbage when using pm3fb' problem ?
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.
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.
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
|
|
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: 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: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: 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: 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: <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 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: 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 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: Sven L. <lu...@dp...> - 2001-06-19 12:41:15
|
On Tue, Jun 19, 2001 at 02:08:11PM +0000, Petr Vandrovec wrote: > On 19 Jun 01 at 13:41, Sven LUTHER wrote: > > On Tue, Jun 19, 2001 at 01:34:43PM +0200, Romain Dolbeau wrote: > > > Sven LUTHER wrote: > > > pm2fb use non-accelerated fbcon-cfb8, and this one > > > simply do pixels = (pixels ^ 0x0f0f0f0f). > > > > > > So I guess it is the answer :-) > > > > Ok, let's go for this, in wait for a response from the more knowledgeable > > fbdev gurus ... > > I do not know whether I'm more knowledgeable, but revc, together with > other character based functions (putc/putcs/clear (and maybe clear_margin)) > have to support only 16 colors. And it is driver bussiness how it will > perform console color -> value in framebuffer mapping. But it is convient, mmm, ok, ... > and couple of apps expects that for pseudocolor console color is directly > stored in framebuffer, so only palette entries 0 .. 15 are used. But > you can use entries 0, 17, 34, 51, 68, ... 238, 255 as well - although you mean using index 0x00, 0x11, 0x22, ... instead of indexes 0, 1, 2, ... > I'm sure that some fbdev apps will not agree with you. Is there some reason to do such ? I suppose the fbcon layer will need to know about this, how do you tell it about it ? > If you decide to use standard way, then using 0xffffffff is correct that is with a writemask, isn't it ? > for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for > 8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor, > 0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot > use RGB332 truecolor without information loss. mmm, truecolor is when the the rgb value is written directly to the pixel ? and pseudo color is when you use a color index table. What exactly is direct color ? pm3 has a bit that you can set, called directcolor, which distinguish between CI8 (pseudocolor) and RGBxxx (truecolor ?) formats. Anyway, the problem only appears in depth 8, since i think that the accel engine knows how to invert color in truecolor format. But in CI8, i think it simply inverts the color index, or something such, so you would have to map the inverted colors in color index 240 to 255. What will happen when an app grabs the framebuffer and plays with it in 256 colors ? will the color map be saved/restored, and in such a case will only the 16 first entries be saved, or all the 256 ones ? Anyway, thanks for the info, ... Friendly, Sven Luther |
|
From: Geert U. <ge...@li...> - 2001-06-19 13:58:18
|
On Tue, 19 Jun 2001, Sven LUTHER wrote:
> On Tue, Jun 19, 2001 at 02:08:11PM +0000, Petr Vandrovec wrote:
> > for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for
> > 8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor,
> > 0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot
> > use RGB332 truecolor without information loss.
>
> mmm, truecolor is when the the rgb value is written directly to the pixel ?
> and pseudo color is when you use a color index table.
>
> What exactly is direct color ?
truecolor:
red = (pixel & redmask) >> redshift
green = (pixel & greenmask) >> greenshift
blue = (pixel & bluemask) >> blueshift
pseudocolor:
red = redtable[pixel]
green = greentable[pixel]
blue = bluetable[pixel]
directcolor:
red = redtable[(pixel & redmask) >> redshift]
green = greentable[(pixel & greenmask) >> greenshift]
blue = bluetable[(pixel & bluemask) >> blueshift]
To make sure revc always does the correct thing, there should be a 17th entry
in the display->dispsw_data telling the invertion mask.
This should be implemented in 2.5.
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: Sven L. <lu...@dp...> - 2001-06-19 14:03:18
|
On Tue, Jun 19, 2001 at 03:55:28PM +0200, Geert Uytterhoeven wrote: > On Tue, 19 Jun 2001, Sven LUTHER wrote: > > On Tue, Jun 19, 2001 at 02:08:11PM +0000, Petr Vandrovec wrote: > > > for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for > > > 8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor, > > > 0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot > > > use RGB332 truecolor without information loss. > > > > mmm, truecolor is when the the rgb value is written directly to the pixel ? > > and pseudo color is when you use a color index table. > > > > What exactly is direct color ? > > truecolor: > > red = (pixel & redmask) >> redshift > green = (pixel & greenmask) >> greenshift > blue = (pixel & bluemask) >> blueshift > > pseudocolor: > > red = redtable[pixel] > green = greentable[pixel] > blue = bluetable[pixel] > > directcolor: > > red = redtable[(pixel & redmask) >> redshift] > green = greentable[(pixel & greenmask) >> greenshift] > blue = bluetable[(pixel & bluemask) >> blueshift] > > To make sure revc always does the correct thing, there should be a 17th entry > in the display->dispsw_data telling the invertion mask. And the correct thing to do is ? Friendly, Sven Luther |
|
From: Geert U. <ge...@li...> - 2001-06-19 14:06:44
|
On Tue, 19 Jun 2001, Sven LUTHER wrote:
> On Tue, Jun 19, 2001 at 03:55:28PM +0200, Geert Uytterhoeven wrote:
> > On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > > On Tue, Jun 19, 2001 at 02:08:11PM +0000, Petr Vandrovec wrote:
> > > > for truecolor and 4bpp pseudocolor, 0x0f0f0f0f is correct for
> > > > 8bpp pseudocolor, 0xXX0f0f0f (*) is for 24/32bpp directcolor,
> > > > 0x3DEF3DEF for 15bpp, 0x79EF79EF for 16bpp, and you cannot
> > > > use RGB332 truecolor without information loss.
> > >
> > > mmm, truecolor is when the the rgb value is written directly to the pixel ?
> > > and pseudo color is when you use a color index table.
> > >
> > > What exactly is direct color ?
> >
> > truecolor:
> >
> > red = (pixel & redmask) >> redshift
> > green = (pixel & greenmask) >> greenshift
> > blue = (pixel & bluemask) >> blueshift
> >
> > pseudocolor:
> >
> > red = redtable[pixel]
> > green = greentable[pixel]
> > blue = bluetable[pixel]
> >
> > directcolor:
> >
> > red = redtable[(pixel & redmask) >> redshift]
> > green = greentable[(pixel & greenmask) >> greenshift]
> > blue = bluetable[(pixel & bluemask) >> blueshift]
> >
> > To make sure revc always does the correct thing, there should be a 17th entry
> > in the display->dispsw_data telling the invertion mask.
>
> And the correct thing to do is ?
EXOR with 15 for pseudocolor
EXOR with -1 for truecolor
EXOR with (15 << redshift | 15 << greenshift | 15 << blueshift) for directcolor
The directcolor case assumes your driver loaded the console palette to the DAC.
Some fbdevs load a linear palette to the DAC so it behaves like truecolor. In
that case, EXOR with -1. That's the reason why we need the 17th entry: fbcon-*
cannot guess easily which mode is being used.
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: Sven L. <lu...@dp...> - 2001-06-19 14:14:13
|
On Tue, Jun 19, 2001 at 04:03:59PM +0200, Geert Uytterhoeven wrote: > On Tue, 19 Jun 2001, Sven LUTHER wrote: > > And the correct thing to do is ? > > EXOR with 15 for pseudocolor mmm, so in the accelerated case, doing a Invert logical op with the writemask set to 0x0f0f0f0f (that is only inverting the lower 4 bits of each pixels) should od the trick. BTW, forgive me if i am being stupid, but why not doing a bitwise not ? Friendly, Sven Luther |
|
From: Geert U. <ge...@li...> - 2001-06-19 14:40:50
|
On Tue, 19 Jun 2001, Sven LUTHER wrote:
> On Tue, Jun 19, 2001 at 04:03:59PM +0200, Geert Uytterhoeven wrote:
> > On Tue, 19 Jun 2001, Sven LUTHER wrote:
> > > And the correct thing to do is ?
> >
> > EXOR with 15 for pseudocolor
>
> mmm, so in the accelerated case, doing a Invert logical op with the writemask
> set to 0x0f0f0f0f (that is only inverting the lower 4 bits of each pixels)
> should od the trick.
>
> BTW, forgive me if i am being stupid, but why not doing a bitwise not ?
Because that would invert too many bits.
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: Romain D. <do...@ir...> - 2001-06-19 14:44:19
|
Geert Uytterhoeven wrote: > > On Tue, 19 Jun 2001, Sven LUTHER wrote: > > BTW, forgive me if i am being stupid, but why not doing a bitwise not ? > > Because that would invert too many bits. I think Sven was thinking of a bitwise not with an hardware mask set to 0x0F0F0F0F, which should have the same result, and with the added benefit that there's no need to transfer the second source of the XOR. So it's easier to do on the permedia3 :-) -- 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: Sven L. <lu...@dp...> - 2001-06-19 14:46:47
|
On Tue, Jun 19, 2001 at 04:38:02PM +0200, Geert Uytterhoeven wrote: > On Tue, 19 Jun 2001, Sven LUTHER wrote: > > On Tue, Jun 19, 2001 at 04:03:59PM +0200, Geert Uytterhoeven wrote: > > > On Tue, 19 Jun 2001, Sven LUTHER wrote: > > > > And the correct thing to do is ? > > > > > > EXOR with 15 for pseudocolor > > > > mmm, so in the accelerated case, doing a Invert logical op with the writemask > > set to 0x0f0f0f0f (that is only inverting the lower 4 bits of each pixels) > > should od the trick. > > > > BTW, forgive me if i am being stupid, but why not doing a bitwise not ? > > Because that would invert too many bits. A ok, ... BTW, any idea about the 'initial garbage when using pm3fb' problem ? friendly, Sven Luther |
|
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: 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: 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 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 :-) |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X