Am 25.02.2012 22:15, schrieb Stefan Weil:
Am 25.02.2012 21:11, schrieb Anthony Liguori:
On
02/25/2012 11:02 AM, Stefan Weil wrote:
Am 20.02.2012 00:44, schrieb Anthony
Liguori:
Hi,
I realize UIs are the third rail of QEMU development, but
over the years I've
gotten a lot of feedback from users about our UI. I think
everyone struggles
with the SDL interface and its lack of discoverability but
it's worse than I
think most people realize for users that rely on
accessibility tools.
The two pieces of feedback I've gotten the most re:
accessibility are the lack
of QEMU's enablement for screen readers and the lack of
configurable
accelerators.
Since we render our own terminal using a fixed sized font,
we don't respect
system font settings which means we ignore if the user has
configured large
print.
We also don't integrate at all with screen readers which
means that for blind
users, the virtual consoles may as well not even exist.
We also don't allow any type of configuration of
accelerators. For users with
limited dexterity (this is actually more common than you
would think), they may
use an input device that only inputs one key at a time.
Holding down two keys
at once is not possible for these users.
These are solved problems though and while we could
reinvent all of this
ourselves with SDL, we would be crazy if we did. Modern
toolkits, like GTK,
solve these problems.
By using GTK, we can leverage VteTerminal for screen
reader integration and font
configuration. We can also use GTK's accelerator support
to make accelerators
configurable (Gnome provides a global accelerator
configuration interface).
I'm not attempting to make a pretty desktop virtualization
UI. Maybe we'll go
there eventually but that's not what this series is about.
This is just attempting to use a richer toolkit such that
we can enable basic
accessibility support. As a consequence, the UI is much
more usable even for a
user without accessibility requirements so it's a win-win.
This first version of the new GTK UI still shares some
problems with
the SDL UI and adds new ones:
It's quite common for the VGA code to set a very small size
(e.g. 1 x 1 pixel)
during boot. MIPS Malta does (if no VGA module like cirrusfb
is loaded,
it will never set a different size), and even the 386 /
x86_64 emulation
has a (very short) time were the display size is unusually
small.
It doesn't. It cycles through modes 640x480, 720x400, then
VGA modes. It never resizes to 1x1.
But.. GTK should handle this better. Even if the drawing
area sets the size to 1x1, the window should maintain a size
at least large enough to render the menu bar properly. ssssssssssssssss
Just run QEMU on a sufficiently slow host, for example QEMU in
QEMU,
or slow down the execution of QEMU by other means, then you will
see
which window sizes are then selected. Maybe you also need
-singlestep.
You _will_ get a very small window!
I just got it using this call on a netbook running Ubuntu:
qemu-system-i386 -L pc-bios -singlestep -d in_asm,out_asm
Don't use KVM, of course - we want to slow down QEMU!
Adding strace is also a good way to reduce execution speed.
Cheers,
Stefan Weil
This also works to get the small window:
gdb --args i386-softmmu/qemu-system-i386 -L pc-bios -singlestep
Set a breakpoint on gd_resize and run. Here is the result (2nd hit
of
the breakpoint):
Breakpoint 2, gd_resize (ds=0x809f7c40) at
/home/stefan/src/qemu/qemu.org/qemu/ui/gtk.c:182
182 GtkDisplayState *s = ds->opaque;
2: ds->surface->width = 9
1: ds->surface->height = 1
So the new window is 9 x 1 pixels.
Regards,
Stefan Weil
|