It seems Kelly Yancey wrote:
I admit that they are less common than say 320x240 mode x...but they are
linear and don't require any hacking to support from applications which
would use graphics modes (unlike the unchained modex modes).
I absolutely agree that we should keep the kernel as
On Tue, 18 May 1999, Kazutaka YOKOTA wrote:
I think you just nailed the problem here. It requires a prohibitive
amount of effort to support modex video modes given the return. What I am
thinking about is removing the 320x240 mode (since it is impossibly
difficult to deal with)...no one is
On Tue, 18 May 1999, Soren Schmidt wrote:
It seems Kelly Yancey wrote:
I admit that they are less common than say 320x240 mode x...but they are
linear and don't require any hacking to support from applications which
would use graphics modes (unlike the unchained modex modes).
I
I'm not really sure what practical use there is for using graphics modes
to render text (and hence why character cell sizes for graphics modes
What if FreeBSD ends up supporting mips or sparc? These machines don't
have anything like VGA text modes, and PROM consoles suck.
that should be
Sorry for not participating in your earlier discussion, I have been
kept busy by my work ;-
The current VGA driver code won't do much in the graphics mode. It
simply switches to a graphics mode when requested, but it has no code
to actually write anything to the video buffer in the graphics
Kazutaka YOKOTA yok...@zodiac.mech.utsunomiya-u.ac.jp writes:
In that sense, the support for 320x240 mode-X is minimal too. The
driver can set up this mode, but has no knowledge or code to write to
it. It is entirely up to the userland program to update the video
buffer. (And it is true
In that sense, the support for 320x240 mode-X is minimal too. The
driver can set up this mode, but has no knowledge or code to write to
it. It is entirely up to the userland program to update the video
buffer. (And it is true that there is very little use to this mode at
the moment as we
On 17 May 1999, Dag-Erling Smorgrav wrote:
Kazutaka YOKOTA yok...@zodiac.mech.utsunomiya-u.ac.jp writes:
In that sense, the support for 320x240 mode-X is minimal too. The
driver can set up this mode, but has no knowledge or code to write to
it. It is entirely up to the userland program
It seems Kelly Yancey wrote:
I think you just nailed the problem here. It requires a prohibitive
amount of effort to support modex video modes given the return. What I am
thinking about is removing the 320x240 mode (since it is impossibly
difficult to deal with)...no one is using it now so
On Mon, 17 May 1999, Soren Schmidt wrote:
It seems Kelly Yancey wrote:
I think you just nailed the problem here. It requires a prohibitive
amount of effort to support modex video modes given the return. What I am
thinking about is removing the 320x240 mode (since it is impossibly
I think you just nailed the problem here. It requires a prohibitive
amount of effort to support modex video modes given the return. What I am
thinking about is removing the 320x240 mode (since it is impossibly
difficult to deal with)...no one is using it now so no one would be
affected. I would
Yes, it can be extended to support all graphics modes (except mode X
:-). But, how useful will it be? The VESA 800x600 raster text mode
was a kludge for some laptop systems, so it was justifiable. But, how
about others? 1024x768 mode can contain only 128 columns if we are to
use 8-dot
On a slightly related note, I am currently in the process of developing
patches to add more useful tweaked modes to the video driver:
graphics 720x480, 16 colors (90x30 8x16 character cells)
graphics 256x256, 256 colors (32x32 8x8 character cells)
graphics 296x220, 256 colors
Kelly Yancey kby...@alcnet.com writes:
Hmm. I sent this message a few days ago and it has been silently ignored.
Should I consider that an OK to extern the get_mode_param function in
vga_isa.c? Or should I take that as a mass go ahead, we're not going to
commit the code anyway? :(
Hmm, well,
On 14 May 1999, Dag-Erling Smorgrav wrote:
Kelly Yancey kby...@alcnet.com writes:
Hmm. I sent this message a few days ago and it has been silently ignored.
Should I consider that an OK to extern the get_mode_param function in
vga_isa.c? Or should I take that as a mass go ahead, we're not
Kelly Yancey kby...@alcnet.com writes:
What I don't get is how the memory is presented to apps using the
driver. The best I could think of would be to present it a 256k linear
frame buffer with the pixels in order (ie writes to consecutive pixels
would result in the driver switching planes),
On 14 May 1999, Dag-Erling Smorgrav wrote:
We already have that (libvgl), though it's in deperate need of
maintenance.
That what I meant by equivalent ;)
Anyway, as you point out, then the modes are really only of use to
splash screens (which is a minor feature in and of itself). So
On 14 May 1999, Dag-Erling Smorgrav wrote:
Kelly Yancey kby...@alcnet.com writes:
What I don't get is how the memory is presented to apps using the
driver. The best I could think of would be to present it a 256k linear
frame buffer with the pixels in order (ie writes to consecutive
Kelly Yancey kby...@alcnet.com writes:
On 14 May 1999, Dag-Erling Smorgrav wrote:
No, actually it has 1536 more pixels :) Mode Q is so named because the
frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors)
Yeah, I've seen the DOS port of snes9x use that. I don't think it has
On 14 May 1999, Dag-Erling Smorgrav wrote:
Kelly Yancey kby...@alcnet.com writes:
On 14 May 1999, Dag-Erling Smorgrav wrote:
No, actually it has 1536 more pixels :) Mode Q is so named because the
frame buffer is a cube of sorts (i.e. 256x256 pixels in 256 colors)
Yeah, I've seen the
To summarize, it seems like a lot of trouble just to get 40 additional
scanlines and square pixels on obsolete hardware - anything that
doesn't support 'options VESA' was already obsolete five years ago.
Unfortunately, it's the trend these days to _not_ support anything at
all interesting in
It seems Mike Smith wrote:
To summarize, it seems like a lot of trouble just to get 40 additional
scanlines and square pixels on obsolete hardware - anything that
doesn't support 'options VESA' was already obsolete five years ago.
Unfortunately, it's the trend these days to _not_ support
Hi!
I don't know about the others, but I look forward to the functionality you may
add.
Regards, Tommy
--- Kelly Yancey kby...@alcnet.com wrote:
Hmm. I sent this message a few days ago and it has been silently ignored.
Should I consider that an OK to extern the get_mode_param function in
On Wed, 12 May 1999, Kazutaka YOKOTA wrote:
Hi,
Hmm. I sent this message a few days ago and it has been silently ignored.
Should I consider that an OK to extern the get_mode_param function in
vga_isa.c? Or should I take that as a mass go ahead, we're not going to
commit the code anyway? :(
Hmm. I sent this message a few days ago and it has been silently ignored.
Should I consider that an OK to extern the get_mode_param function in
vga_isa.c? Or should I take that as a mass go ahead, we're not going to
commit the code anyway? :(
Thanks,
Kelly
~kby...@alcnet.com~
FreeBSD -
25 matches
Mail list logo
