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:av1...@comtv.ru