Re: beginnings of allowing more than the basic 80x25 VGA screen resolution

Re: beginnings of allowing more than the basic 80x25 VGA screen resolution

[Keir Fraser]

On 4 Jul 2005, at 09:00, Jan Beulich wrote:

> As far as I know, not only the VGA driver does not do any mode
> switching, even the VESA one doesn't (because the protected mode
> interface doesn't cover the mode switching functions as far as I
> remember). Only the video board specific frame buffer drivers are able
> to switch modes, and the bad thing (for me personally) is that even in
> 2.6.12 there still is no (64-bit) support for the i915 chipset. So I
> continue to be required to live with the video mode that XEN 'sets'
> prior to loading dom0, and short of it supporting a VESA console my
> first minimal attempt was to at least increase (and propagate) the size
> to the maximum possible without significant changes.

That's a pain. Maybe we can find a simple example somewhere of setting 
video mode via protect-mode VBE calls. I see that this functionality is 
missing from the kernel drivers -- it's all done in a monstrous 
real-mode assembly file. Any video card we care about these days should 
support VBE 2.0/3.0 I think, and those interfaces don;t require you to 
be runnign in real mode.

  -- Keir

Re: beginnings of allowing more than the basic 80x25 VGA screen resolution

[Gerd Knorr]

Keir Fraser <Keir.Fraser@cl.cam.ac.uk> writes:

> > As far as I know, not only the VGA driver does not do any mode
> > switching, even the VESA one doesn't (because the protected mode

Exactly.  A simple way to get more screen lines is to load a 8x8
screen font though.

> real-mode assembly file. Any video card we care about these days
> should support VBE 2.0/3.0 I think, and those interfaces don;t require
> you to be runnign in real mode.

vbe 2.0 yes, not sure about 3.0.

For mode switching from protected mode you need 3.0 though, 2.0
protected mode support is _very_ limited (you can do panning and
palette register programming, but no mode switching).  And I think
even for vbe 3.0 you need some real mode code to figure the protected
mode entry point, so paravirtual linux wouldn't be able to do that
without help from xen.

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */

Re: beginnings of allowing more than the basic 80x25 VGA screen resolution

[Matthias Huber]

Gerd Knorr <kraxel <at> suse.de> writes:

> 
> Keir Fraser <Keir.Fraser <at> cl.cam.ac.uk> writes:
> 
> > > As far as I know, not only the VGA driver does not do any mode
> > > switching, even the VESA one doesn't (because the protected mode
> 
> Exactly.  A simple way to get more screen lines is to load a 8x8
> screen font though.
> 
> > real-mode assembly file. Any video card we care about these days
> > should support VBE 2.0/3.0 I think, and those interfaces don;t require
> > you to be runnign in real mode.
> 
> vbe 2.0 yes, not sure about 3.0.
> 
> For mode switching from protected mode you need 3.0 though, 2.0
> protected mode support is _very_ limited (you can do panning and
> palette register programming, but no mode switching).  And I think
> even for vbe 3.0 you need some real mode code to figure the protected
> mode entry point, so paravirtual linux wouldn't be able to do that
> without help from xen.

The VBE3.0 spec shows clearly how to figure out the protected mode entry point:
copy the video bios to another location and search for the PMInfoBlock
structure, identified by a four-byte signature "PMID". In the structure you find
the protected mode entry point.
At the moment I am working on initializing graphics mode via the protected mode
VBE interface. So far I found the PMInfoBlock, now I try to figure out how to
set up the needed 16bit-registers to do the lcall into the video bios (at the
protected mode entry point). Any code snippets e.g. for switching to a 16bit
stack selector prior to the lcall are wellcome...

Matthias Huber

Re: Re: beginnings of allowing more than the basic 80x25 VGA screen resolution

[Gerd Knorr]

Matthias Huber <hubermat@gmx.de> writes:

> protected mode entry point). Any code snippets e.g. for switching to a 16bit
> stack selector prior to the lcall are wellcome...

linux apm code should have something, apm bios is 16 bit as well.

HTH,

  Gerd

-- 
panic("it works"); /* avoid being flooded with debug messages */