>> > > 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
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)
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 o
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 ker
>> 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
> 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
> 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 wo
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
>
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 s
On 17 May 1999, Dag-Erling Smorgrav wrote:
> Kazutaka YOKOTA 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.
>> 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 mome
Kazutaka YOKOTA 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 that there is very little use to this
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 mode
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_ s
> 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 i
On 14 May 1999, Dag-Erling Smorgrav wrote:
> Kelly Yancey 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 por
Kelly Yancey 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
> truely sq
On 14 May 1999, Dag-Erling Smorgrav wrote:
> Kelly Yancey 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
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 its
Kelly Yancey 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), and while tha
On 14 May 1999, Dag-Erling Smorgrav wrote:
> Kelly Yancey 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
>
Kelly Yancey 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, I don't like
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
Hi!
I don't know about the others, but I look forward to the functionality you may
add.
Regards, Tommy
--- Kelly Yancey 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
> vga_isa.c? Or sh
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
