Re: building vgabios-stdvga.bin

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>> With this questionable version of dev86, I went back to the kvm/vgabios
>> directory and tried to build there again.  Much to my surprise, it
>> actually ran, and built 4 variants on VGABIOS-lgpl-latest.bin...
>> Cool, says I, now what do I do with these?  I did the only thing
>> I could think of, and installed VGA-lgpl-latest.bin as
>
> Almost correct.  You need VGABIOS-lgpl-latest.stdvga.bin

That sounds great, but unfortunately, the build didn't create that one.

It created the following:

    VGABIOS-lgpl-latest.bin
    VGABIOS-lgpl-latest.cirrus.bin
    VGABIOS-lgpl-latest.cirrus.debug.bin
    VGABIOS-lgpl-latest.debug.bin

> Thats the one qemu is using.  Also available from
>     http://git.qemu.org/?p=vgabios.git;a=summary

I pulled this version down.  Indeed, it does build several
additional versions, including stdvga.  Hurray!

I don't know if this is the right place to make this suggestion,
but it would be nice if this version could make it into the
qemu-kvm distribution.

Now, if I may add a few more questions...

I've been experimenting with adding some special-purpose resolutions,
and I've had some rather mixed success.  I've found that I get
varying results depending on the width and color depth I use.

For example, with 32-bit color depth, if I use a width of 2560,
it works perfectly, but if I use 2556, the screen only resizes
vertically to reflect the new resolution, and the screen fills
with garbage.  I thought that perhaps it needs an integer multiple
of some power of two, so I started backing it off by progressively
larger powers of two.  At a width of 2552, the guest crashes
completely.  At 2544, 2528, 2496, and 2432, it works, but I get
some very odd artifacts, both in the mouse cursor and in places
where the mouse cursor has been recently.  If I bring it all the way
down to 2304 (nearest multiple of 256), everything seems to work
properly again.

At 24-bit color depth, I get better results.  2556 is still garbage,
but 2552 and below now work just fine.  (Actually, 2552 crashed once,
but I think maybe I accidentally clicked on 32-bit color instead of 24.
I hope so, anyway)

Do you know what the real constraints are?  Do you know if they're
imposed by the vgabios driver, the VNC module, or the guest
operating system (Windows 7 in this case)?

And perhaps most importantly, is this a bug that can be fixed?
I can live with needing a multiple of 8, but 256 seems a little
extreme (and unlikely, given that 800x600 works).  It would be
nice if I could use 32-bit color with my chosen resolution.

I'd be happy to go looking for the bug myself, but if you happen
to know off the top of your head where to look, or whether it's
an impossible dream, that would save me a lot of time.  This isn't
exactly my normal area of expertise.

    -- Rick
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [KVM ARM]     [KVM ia64]     [KVM ppc]     [Virtualization Tools]     [Spice Development]     [Libvirt]     [Libvirt Users]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite Questions]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux