From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:51922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1Oy1-0001ql-9c for qemu-devel@nongnu.org; Sat, 25 Feb 2012 16:15:51 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S1Oxu-0002gA-Td for qemu-devel@nongnu.org; Sat, 25 Feb 2012 16:15:45 -0500 Received: from v220110690675601.yourvserver.net ([78.47.199.172]:55755) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S1Oxu-0002g1-Jz for qemu-devel@nongnu.org; Sat, 25 Feb 2012 16:15:38 -0500 Message-ID: <4F494F75.7080802@weilnetz.de> Date: Sat, 25 Feb 2012 22:15:33 +0100 From: Stefan Weil MIME-Version: 1.0 References: <1329695104-15174-1-git-send-email-aliguori@us.ibm.com> <4F491423.7060300@weilnetz.de> <4F494064.4070501@codemonkey.ws> In-Reply-To: <4F494064.4070501@codemonkey.ws> Content-Type: multipart/alternative; boundary="------------020401030905040703040901" Subject: Re: [Qemu-devel] [PATCH 0/6] Add GTK UI to enable basic accessibility List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org This is a multi-part message in MIME format. --------------020401030905040703040901 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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. ss/ssssssssssssss/ 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 PS. qemu-system-i386 crashed like qemu-system-mipsel before when it tried to switch from the small window to the normal size: The program '' received an X Window System error. This probably reflects a bug in the program. The error was 'BadAlloc (insufficient resources for operation)'. (Details: serial 351 error_code 11 request_code 53 minor_code 0) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) Debugging X errors is a bit difficult, but I finally got this backtrace: Breakpoint 3, 0x00438196 in _XError () from /usr/lib/libX11.so.6 (gdb) i s #0 0x00438196 in _XError () from /usr/lib/libX11.so.6 #1 0x0043e92f in ?? () from /usr/lib/libX11.so.6 #2 0x0043f356 in _XEventsQueued () from /usr/lib/libX11.so.6 #3 0x0043f3e9 in _XFlush () from /usr/lib/libX11.so.6 #4 0x00417101 in XFlush () from /usr/lib/libX11.so.6 #5 0x00936cb4 in gdk_display_flush () from /usr/lib/libgdk-x11-2.0.so.0 #6 0x00928f7a in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0 #7 0x005c676f in ?? () from /usr/lib/libgtk-x11-2.0.so.0 #8 0x00905358 in ?? () from /usr/lib/libgdk-x11-2.0.so.0 #9 0x00176661 in ?? () from /lib/libglib-2.0.so.0 #10 0x001785e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0 #11 0x8013d4a0 in glib_select_poll (rfds=0xbfffef04, wfds=0xbfffee84, xfds=0xbfffee04, err=false) at /home/stefan/src/qemu/qemu.org/qemu/main-loop.c:287 #12 0x8013d696 in main_loop_wait (nonblocking=0) at /home/stefan/src/qemu/qemu.org/qemu/main-loop.c:463 #13 0x80131b40 in main_loop () at /home/stefan/src/qemu/qemu.org/qemu/vl.c:1482 #14 0x80138985 in main (argc=6, argv=0xbffff344, envp=0xbffff360) at /home/stefan/src/qemu/qemu.org/qemu/vl.c:3541 --------------020401030905040703040901 Content-Type: text/html; charset=ISO-8859-15 Content-Transfer-Encoding: quoted-printable 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.=A0 It cycles through modes 640x480, 720x400, then VGA modes.=A0 It never resizes to 1x1.

But..=A0 GTK should handle this better.=A0 Even if the drawing ar= ea sets the size to 1x1, the window should maintain a size at least large enough to render the menu bar properly.=A0ss<= i>ssssssssssssss

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

PS. qemu-system-i386 crashed like qemu-system-mipsel before
when it tried to switch from the small window to the normal size:
The program '<unknown>' received an X Window System error. This probably reflects a bug in the program.
The error was 'BadAlloc (insufficient resources for operation)'. =A0 (Details: serial 351 error_code 11 request_code 53 minor_code 0= )
=A0 (Note to programmers: normally, X errors are reported asynchronously;
=A0=A0 that is, you will receive the error a while after causing it= .
=A0=A0 To debug your program, run it with the --sync command line =A0=A0 option to change this behavior. You can then get a meaningfu= l
=A0=A0 backtrace from your debugger if you break on the gdk_x_error= () function.)

Debugging X errors is a bit difficult, but I finally got this backtrace:

Breakpoint 3, 0x00438196 in _XError () from /usr/lib/libX11.so.6 (gdb) i s
#0=A0 0x00438196 in _XError () from /usr/lib/libX11.so.6
#1=A0 0x0043e92f in ?? () from /usr/lib/libX11.so.6
#2=A0 0x0043f356 in _XEventsQueued () from /usr/lib/libX11.so.6
#3=A0 0x0043f3e9 in _XFlush () from /usr/lib/libX11.so.6
#4=A0 0x00417101 in XFlush () from /usr/lib/libX11.so.6
#5=A0 0x00936cb4 in gdk_display_flush () from /usr/lib/libgdk-x11-2.0.so.0
#6=A0 0x00928f7a in gdk_window_process_all_updates () from /usr/lib/libgdk-x11-2.0.so.0
#7=A0 0x005c676f in ?? () from /usr/lib/libgtk-x11-2.0.so.0
#8=A0 0x00905358 in ?? () from /usr/lib/libgdk-x11-2.0.so.0
#9=A0 0x00176661 in ?? () from /lib/libglib-2.0.so.0
#10 0x001785e5 in g_main_context_dispatch () from /lib/libglib-2.0.so.0
#11 0x8013d4a0 in glib_select_poll (rfds=3D0xbfffef04, wfds=3D0xbfffee84, xfds=3D0xbfffee04,
=A0=A0=A0 err=3Dfalse) at /home/stefan/src/qemu/qemu.org/qemu/main-loop.c:287
#12 0x8013d696 in main_loop_wait (nonblocking=3D0)
=A0=A0=A0 at /home/stefan/src/qemu/qemu.org/qemu/main-loop.c:463 #13 0x80131b40 in main_loop () at /home/stefan/src/qemu/qemu.org/qemu/vl.c:1482
#14 0x80138985 in main (argc=3D6, argv=3D0xbffff344, envp=3D0xbffff= 360)
=A0=A0=A0 at /home/stefan/src/qemu/qemu.org/qemu/vl.c:3541

 --------------020401030905040703040901--