Menu
▾
▴
linuxconsole-dev
|
From: Petr V. <VAN...@vc...> - 2000-08-30 16:56:05
|
On 30 Aug 00 at 8:04, James Simmons wrote: > > ftp://platan.vc.cvut.cz/pub/linux/matrox-latest/2.4.0-test7-vgatext.gz. > > It contains patch for 2.4.0-test7 which adds textmode and 8bpp modes > > to vga16fb driver (8bpp of course only 320x200 cfb8 or 360x480 planar 8, > > as standard VGA knows). > > Nice. Support even for Mode X :-) I will take a look at it in depth. The Yes. And it even works... But 'cfb4' code (yes, even such thing is possible on VGA) works only on some hardware... On other hardware you can have swapped even and odd pixel columns (swapped nibbles in byte...). If memory serves correctly, current version works on ATI chips, but does not on Matrox and C&T products. > one thing I like to see is vgacon set the video mode itself instead of > depending on the system firmware. The reason being is usually firmware is Problem is that for example Matrox devices are totaly dead after powerup. And enabling framebuffer region and accessing it can cause PCI bus lockup, because of memory clock (on old Millennium I) are programmed for 0Hz, so PCI read cycle never finish. Petr |
|
From: Brad D. <Br...@NE...> - 2000-08-30 17:38:05
|
> > Although I think that we should leave VGA alone. It is just too painful > > to try multihead on such hardware... > > True. It would be a pain to make vgacon work with other vgacon drivers. It > is no problem with another fbcon or mdacon driver. The VBE 3 spec. does make some allotment for dual card systems. It allows for relocation of the video BIOS and the second card would act as a slave to the primary card. So in theory, two video cards should be able to be supported via vgacon. The question is, how many cards actually support VBE 3? Brad Douglas br...@ne... http://www.linux-fbdev.org |
|
From: James S. <jsi...@ac...> - 2000-08-31 13:09:17
|
> > True. It would be a pain to make vgacon work with other vgacon drivers. It > > is no problem with another fbcon or mdacon driver. > > The VBE 3 spec. does make some allotment for dual card systems. It allows > for relocation of the video BIOS and the second card would act as a slave to > the primary card. So in theory, two video cards should be able to be > supported via vgacon. The question is, how many cards actually support VBE > 3? About as many that support VESA 2.0. I have 6 video cards and not one supports VESA 2.0. Even fewer support VESA 3.0. Yes their is a VESA 3.0 standard that allows nice things like changing the video mode after boot time via BIOS calls in protect mode. MS: (n) 1. A debilitating and surprisingly widespread affliction that renders the sufferer barely able to perform the simplest task. 2. A disease. James Simmons [jsi...@li...] ____/| fbdev/console/gfx developer \ o.O| http://www.linux-fbdev.org =(_)= http://linuxgfx.sourceforge.net U http://linuxconsole.sourceforge.net |
|
From: <jmc...@li...> - 2000-08-31 19:23:20
|
James Simmons <jsi...@ac...> wrote: > About as many that support VESA 2.0. I have 6 video cards and not one > supports VESA 2.0. Even fewer support VESA 3.0. Yes their is a VESA 3.0 > standard that allows nice things like changing the video mode after boot > time via BIOS calls in protect mode. I once wrote a device driver for Linux that used the VESA 3 protected mode code, but it wouldn't work for setting video modes for ANY card that advertised itself as VESA 3. This was in Spring '99, and things may have changed since then, but I doubt it. A contact I had at SciTech said that the problem lay in the fact that there were NO commercially availible testing suites for the VESA 3.0 protect mode spec. (You can get my code at: http://zhrodague.net/~jmcc/vesa3/ ) -- Jason McMullan, Senior Linux Consultant, Linuxcare, Inc. 412.422.8077 tel, 412.656.3519 cell, 415.701.0792 fax jmc...@li..., http://www.linuxcare.com/ Linuxcare. Support for the revolution. |
|
From: Petr V. <VAN...@vc...> - 2000-08-31 16:37:47
|
On 31 Aug 00 at 9:18, James Simmons wrote:
> > > Nice. Support even for Mode X :-) I will take a look at it in depth. The
> >
> > Yes. And it even works...
>
> Great. Will merge with CVS code soon.
Thanks.
> > Problem is that for example Matrox devices are totaly dead after powerup.
> > And enabling framebuffer region and accessing it can cause PCI bus lockup,
> > because of memory clock (on old Millennium I) are programmed for 0Hz,
> > so PCI read cycle never finish.
>
> What I mean is read the values from the vga hardware instead of from
> screeninfo which is provided by the firmware.
If you want to support only standard modes (text, cfb8, vgaplanes,
vga8planes), it is easy. But there is couple of more or less nonstandard
modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with
character generator disabled (gives you `spectrum like' attribute + 8pixels).
What to do with them? Let them fall through and report something similar
for them?
If you are talking only about recognition of currently used videomode
at startup, it should be possible, and possibly trivial. I have
(in mgadump) code which adds `correct' constants and sums correct
bits together to get all picture sizes... Should I port that code
to Linux and send it to you?
Petr
|
|
From: Vojtech P. <vo...@su...> - 2000-08-31 21:02:35
|
On Thu, Aug 31, 2000 at 06:36:08PM +0000, Petr Vandrovec wrote: > If you want to support only standard modes (text, cfb8, vgaplanes, > vga8planes), it is easy. But there is couple of more or less nonstandard > modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with > character generator disabled (gives you `spectrum like' attribute + 8pixels). > What to do with them? Let them fall through and report something similar > for them? The 1-line font (which you describe as spectrum-like) actually could be quite useful for having a huge font, while still keeping minimum video memory size. -- Vojtech Pavlik SuSE Labs |
|
From: James S. <jsi...@ac...> - 2000-09-01 13:10:27
|
> > What I mean is read the values from the vga hardware instead of from > > screeninfo which is provided by the firmware. > > If you want to support only standard modes (text, cfb8, vgaplanes, > vga8planes), it is easy. But there is couple of more or less nonstandard > modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with > character generator disabled (gives you `spectrum like' attribute + 8pixels). > What to do with them? Let them fall through and report something similar > for them? Wow. I never even seen any spectrum modes in any books. Where did you learn about it? > If you are talking only about recognition of currently used videomode > at startup, it should be possible, and possibly trivial. I have > (in mgadump) code which adds `correct' constants and sums correct > bits together to get all picture sizes... Should I port that code > to Linux and send it to you? Pretty much I'm talking about recongnition of currently used videomode but it would also be nice to support other "non-standard modes". I would like to see your code :-) |
|
From: Petr V. <VAN...@vc...> - 2000-08-31 21:31:23
|
On 31 Aug 00 at 23:01, Vojtech Pavlik wrote:
> On Thu, Aug 31, 2000 at 06:36:08PM +0000, Petr Vandrovec wrote:
>
> > If you want to support only standard modes (text, cfb8, vgaplanes,
> > vga8planes), it is easy. But there is couple of more or less nonstandard
> > modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with
> > character generator disabled (gives you `spectrum like' attribute + 8pixels).
> > What to do with them? Let them fall through and report something similar
> > for them?
>
> The 1-line font (which you describe as spectrum-like) actually could be
> quite useful for having a huge font, while still keeping minimum video
> memory size.
Problem is that standard VGA can use only 64KB (VGA text compat.),
or 128KB (when VGA hardware in real 4plane mode) in that mode, as planes
2 & 3 are reserved for character generator and unused... This
limits you to either 80x409 (~ 640x409) or 80x819 (or 100x655 (~800x655))...
This is not too much - it is same as 4plane modes (real textmode with
8x16 font gives you virtual screen 640x6544, BTW).
And unfortunately, although bmove works on same speed as in 4plane mode,
putc/putcs are much slower, as you cannot use special VGA write modes :-(
16 writes in 128KB mode, instead of 8 for 4plane...
Best regards,
Petr Vandrovec
van...@vc...
|
|
From: Vojtech P. <vo...@su...> - 2000-08-31 21:33:53
|
On Thu, Aug 31, 2000 at 11:30:04PM +0000, Petr Vandrovec wrote: > On 31 Aug 00 at 23:01, Vojtech Pavlik wrote: > > On Thu, Aug 31, 2000 at 06:36:08PM +0000, Petr Vandrovec wrote: > > > > > If you want to support only standard modes (text, cfb8, vgaplanes, > > > vga8planes), it is easy. But there is couple of more or less nonstandard > > > modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with > > > character generator disabled (gives you `spectrum like' attribute + 8pixels). > > > What to do with them? Let them fall through and report something similar > > > for them? > > > > The 1-line font (which you describe as spectrum-like) actually could be > > quite useful for having a huge font, while still keeping minimum video > > memory size. > > Problem is that standard VGA can use only 64KB (VGA text compat.), > or 128KB (when VGA hardware in real 4plane mode) in that mode, as planes > 2 & 3 are reserved for character generator and unused... This > limits you to either 80x409 (~ 640x409) or 80x819 (or 100x655 (~800x655))... This is just fine for 80x25 text w/ unlimited font ... (80x25 is 720x400, assuming 9-bit mode). > This is not too much - it is same as 4plane modes (real textmode with > 8x16 font gives you virtual screen 640x6544, BTW). > > And unfortunately, although bmove works on same speed as in 4plane mode, > putc/putcs are much slower, as you cannot use special VGA write modes :-( > 16 writes in 128KB mode, instead of 8 for 4plane... > Best regards, > Petr Vandrovec > van...@vc... > -- Vojtech Pavlik SuSE Labs |
|
From: Petr V. <VAN...@vc...> - 2000-09-01 15:21:18
|
On 1 Sep 00 at 9:22, James Simmons wrote:
> > > What I mean is read the values from the vga hardware instead of from
> > > screeninfo which is provided by the firmware.
> >
> > If you want to support only standard modes (text, cfb8, vgaplanes,
> > vga8planes), it is easy. But there is couple of more or less nonstandard
> > modes too. 2 (1plane) or 4-color (2planes) modes, alphanumeric mode with
> > character generator disabled (gives you `spectrum like' attribute + 8pixels).
> > What to do with them? Let them fall through and report something similar
> > for them?
>
> Wow. I never even seen any spectrum modes in any books. Where did you
> learn about it?
It must work that way... I was asking myself why there are two alphanumeric-
-graphics switches. One says whether pass data through character generator,
second says whether it is data+attr, or 4plane data...
Another solution is using documented interface and simple create 1 line
tall font with 1:1 mapping (0->0, 1->1,... 255->255).
> > If you are talking only about recognition of currently used videomode
> > at startup, it should be possible, and possibly trivial. I have
> > (in mgadump) code which adds `correct' constants and sums correct
> > bits together to get all picture sizes... Should I port that code
> > to Linux and send it to you?
>
> Pretty much I'm talking about recongnition of currently used videomode but
> it would also be nice to support other "non-standard modes". I would like
> to see your code :-)
OK, I'll port it during weekend.
Petr
|
|
From: James S. <jsi...@ac...> - 2000-08-31 13:07:03
|
> > Nice. Support even for Mode X :-) I will take a look at it in depth. The > > Yes. And it even works... Great. Will merge with CVS code soon. > > one thing I like to see is vgacon set the video mode itself instead of > > depending on the system firmware. The reason being is usually firmware is > > Problem is that for example Matrox devices are totaly dead after powerup. > And enabling framebuffer region and accessing it can cause PCI bus lockup, > because of memory clock (on old Millennium I) are programmed for 0Hz, > so PCI read cycle never finish. What I mean is read the values from the vga hardware instead of from screeninfo which is provided by the firmware. |
×
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