On Wed, 18 Apr 2012, Gerd Hoffmann wrote:
> Hi,
>> [ adding seabios list to Cc:, topic is the missing vesa 2.0 protected
> mode interface in seavgabios ]
>> >> Pointer?
> >> I'd like to have a test case which breaks with the new vgabios.
> >
> > We talked with malc briefly on irc yesterday, and this is what
> > he gave me:
> >
> > http://cvs.savannah.gnu.org/viewvc/vgabios/vbe.c?root=vgabios&r1=1.47&r2=1.48> >
> > this is not the test case but the missing support he's referring to.
> >
> > It appears the patch implements just 2 functions which both just does
> > int10,
>> It isn't that simple. Just invoking int10 from protected mode isn't
> guaranteed to have the desired effect. It certainly wouldn't work for
> linux vesafb panning. It might work for dos extenders, they might have
> the idt entry for int10 and other bios interrupts setup accordingly to
> do a real-mode -> bios call -> protected mode transition to simplify
> porting dos code to the 32bit extender. But even for that use case it
> is IMHO pointless as the reason to have a 32bit interface is to avoid
> the expensive real mode switch in the first place ...
I needed DOS to work and it did, for me, in turn, linux vesafb is
pointless.
>> The code has been changed later on, for good reasons, see
>http://git.qemu.org/?p=vgabios.git;a=commitdiff;h=72c270d8091fb0f09e8291cc0e7154b075b921a9>> > so should be easy to implement in seabios,
>> seavgabios has no 32bit code at all at the moment. vesa pmi didn't seem
> to be important enougth to change it.
>> seabios is a 16/32bit hybrid with some code being compiled twice for
> both modes; dunno how reusable the seabios infrastructure is. Unlike
> seabios seavgabios has no fixed load address, which makes things a bit
> more complicated when it comes to global variables I think.
>> At least for the bochs interface this wouldn't be a showstopper though.
> Instead of using global variables to figure stuff like the active video
> mode we can just read the bits we need from the bochs device registers.
> Costs some extra vmexits of course, and we wouldn't have code sharing
> for 16+32bit paths.
>> cheers,
> Gerd
>
--
mailto:av1474 at comtv.ru