[Qemu-devel] [PULL for-2.8 0/3] ui: bugfixes for gtk, curses and hid emulation.

[Qemu-devel] [PULL for-2.8 0/3] ui: bugfixes for gtk, curses and hid emulation.

[Gerd Hoffmann]

  Hi,

Here is the UI patch queue with three bugfixes,
most importantly the cursesw configure fix.

please pull,
  Gerd

The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e:

  Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging (2016-11-07 14:02:15 +0000)

are available in the git repository at:


  git://git.kraxel.org/qemu tags/pull-ui-20161109-1

for you to fetch changes up to ba60f2d18e976ef99238ebce019e26719f2b597c:

  Fix cursesw detection (2016-11-09 14:35:47 +0100)

----------------------------------------------------------------
ui: bugfixes for gtk, curses and hid emulation.

----------------------------------------------------------------
Peter Korsgaard (1):
      hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc

Samuel Thibault (1):
      Fix cursesw detection

Thomas Huth (1):
      ui/gtk: Fix build with older versions of gtk

 configure      | 7 ++++++-
 hw/input/hid.c | 4 ++--
 ui/gtk.c       | 3 ++-
 3 files changed, 10 insertions(+), 4 deletions(-)

[Qemu-devel] [PULL 1/3] ui/gtk: Fix build with older versions of gtk

[Gerd Hoffmann]

From: Thomas Huth <thuth@redhat.com>

GDK_KEY_Delete is only defined with gtk version 2.22 and newer,
on older versions this key was called GDK_Delete instead.
Since this is the case for all GDK_KEY_* defines, change the
already existing preprocessor check there to test for version 2.22,
so we know that we can remove this code block in case we require
that version as a minimum one day.

Signed-off-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Daniel P. Berrange <berrange@redhat.com>
Message-id: 1478081328-25515-1-git-send-email-thuth@redhat.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 ui/gtk.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/ui/gtk.c b/ui/gtk.c
index ca737c4..e816428 100644
--- a/ui/gtk.c
+++ b/ui/gtk.c
@@ -94,7 +94,7 @@
 #define GDK_IS_WIN32_DISPLAY(dpy) (dpy == dpy)
 #endif
 
-#ifndef GDK_KEY_0
+#if !GTK_CHECK_VERSION(2, 22, 0)
 #define GDK_KEY_0 GDK_0
 #define GDK_KEY_1 GDK_1
 #define GDK_KEY_2 GDK_2
@@ -104,6 +104,7 @@
 #define GDK_KEY_plus GDK_plus
 #define GDK_KEY_minus GDK_minus
 #define GDK_KEY_Pause GDK_Pause
+#define GDK_KEY_Delete GDK_Delete
 #endif
 
 /* Some older mingw versions lack this constant or have
-- 
1.8.3.1

[Qemu-devel] [PULL 2/3] hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc

[Gerd Hoffmann]

From: Peter Korsgaard <peter@korsgaard.com>

The printscreen/sysrq and pause/break keys currently don't work for guests
using -usbdevice keyboard when accessed through vnc with a gtk-vnc based
client.

The reason for this is a mismatch between gtk-vnc and qemu in how these keys
should be mapped to XT keycodes.

On the original IBM XT these keys behaved differently than other keys.

Quoting from https://www.win.tue.nl/~aeb/linux/kbd/scancodes-1.html:

The keys PrtSc/SysRq and Pause/Break are special. The former produces
scancode e0 2a e0 37 when no modifier key is pressed simultaneously, e0 37
together with Shift or Ctrl, but 54 together with (left or right) Alt.  (And
one gets the expected sequences upon release.  But see below.) The latter
produces scancode sequence e1 1d 45 e1 9d c5 when pressed (without modifier)
and nothing at all upon release.  However, together with (left or right)
Ctrl, one gets e0 46 e0 c6, and again nothing at release.  It does not
repeat.

Gtk-vnc supports the 'QEMU Extended Key Event Message' RFB extension to send
raw XT keycodes directly to qemu, but the specification doesn't explicitly
specify how to map such long/complicated keycode sequences.  From the spec
(https://github.com/rfbproto/rfbproto/blob/master/rfbproto.rst#qemu-extended-key-event-message)

The keycode is the XT keycode that produced the keysym. An XT keycode is an
XT make scancode sequence encoded to fit in a single U32 quantity.  Single
byte XT scancodes with a byte value less than 0x7f are encoded as is.
2-byte XT scancodes whose first byte is 0xe0 and second byte is less than
0x7f are encoded with the high bit of the first byte set

hid.c currently expects the keycode sequence with shift/ctl for sysrq (e0 37
-> 0xb7 in RFB), whereas gtk-vnc uses the sequence with alt (0x54).
Likewise, hid.c expects the code without modifiers (e1 1d 45 -> 0xc5 in
RFB), whereas gtk-vnc sends the keycode sequence with ctrl for pause (e0 46
-> 0xc6 in RFB).

See keymaps.cvs in gtk-vnc for the mapping used:
https://git.gnome.org/browse/gtk-vnc/tree/src/keymaps.csv#n150

Now, it isn't obvious to me which sequence is really "right", but as the
0x54/0xc6 keycodes are currently unused in hid.c, supporting both seems like
the pragmatic solution to me.  The USB HID keyboard boot protocol used by
hid.c doesn't have any other mapping applicable to these keys.

The other guest keyboard interfaces (ps/2, virtio, ..) are not affected,
because they handle these keys differently.

Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Message-id: 20161028145132.1702-1-peter@korsgaard.com
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 hw/input/hid.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/hw/input/hid.c b/hw/input/hid.c
index 5e2850e..fa9cc4c 100644
--- a/hw/input/hid.c
+++ b/hw/input/hid.c
@@ -46,7 +46,7 @@ static const uint8_t hid_usage_keys[0x100] = {
     0xe2, 0x2c, 0x39, 0x3a, 0x3b, 0x3c, 0x3d, 0x3e,
     0x3f, 0x40, 0x41, 0x42, 0x43, 0x53, 0x47, 0x5f,
     0x60, 0x61, 0x56, 0x5c, 0x5d, 0x5e, 0x57, 0x59,
-    0x5a, 0x5b, 0x62, 0x63, 0x00, 0x00, 0x64, 0x44,
+    0x5a, 0x5b, 0x62, 0x63, 0x46, 0x00, 0x64, 0x44,
     0x45, 0x68, 0x69, 0x6a, 0x6b, 0x6c, 0x6d, 0x6e,
     0xe8, 0xe9, 0x71, 0x72, 0x73, 0x00, 0x00, 0x00,
     0x00, 0x00, 0x00, 0x85, 0x00, 0x00, 0x00, 0x00,
@@ -61,7 +61,7 @@ static const uint8_t hid_usage_keys[0x100] = {
     0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
     0x00, 0x00, 0x00, 0x00, 0x00, 0x54, 0x00, 0x46,
     0xe6, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
-    0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x00, 0x4a,
+    0x00, 0x00, 0x00, 0x00, 0x00, 0x48, 0x48, 0x4a,
     0x52, 0x4b, 0x00, 0x50, 0x00, 0x4f, 0x00, 0x4d,
     0x51, 0x4e, 0x49, 0x4c, 0x00, 0x00, 0x00, 0x00,
     0x00, 0x00, 0x00, 0xe3, 0xe7, 0x65, 0x00, 0x00,
-- 
1.8.3.1

[Qemu-devel] [PULL 3/3] Fix cursesw detection

[Gerd Hoffmann]

From: Samuel Thibault <samuel.thibault@ens-lyon.org>

On systems which do not provide ncursesw.pc and whose /usr/include/curses.h
does not include wide support, we should not only try with no -I, i.e.
/usr/include, but also with -I/usr/include/ncursesw.

To properly detect for wide support with and without -Werror, we need to
check for the presence of e.g. the WACS_DEGREE macro.

We also want to stop at the first curses_inc_list configuration which works,
and make sure to set IFS to : at each new loop.

Signed-off-by: Samuel Thibault <samuel.thibault@ens-lyon.org>
Tested-by: Cornelia Huck <cornelia.huck@de.ibm.com>
Message-id: 20161109102752.13255-1-samuel.thibault@ens-lyon.org
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
---
 configure | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index fd6f898..7d2a34e 100755
--- a/configure
+++ b/configure
@@ -2926,7 +2926,7 @@ if test "$curses" != "no" ; then
     curses_inc_list="$($pkg_config --cflags ncurses 2>/dev/null):"
     curses_lib_list="$($pkg_config --libs ncurses 2>/dev/null):-lpdcurses"
   else
-    curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):"
+    curses_inc_list="$($pkg_config --cflags ncursesw 2>/dev/null):-I/usr/include/ncursesw:"
     curses_lib_list="$($pkg_config --libs ncursesw 2>/dev/null):-lncursesw:-lcursesw"
   fi
   curses_found=no
@@ -2941,11 +2941,13 @@ int main(void) {
   resize_term(0, 0);
   addwstr(L"wide chars\n");
   addnwstr(&wch, 1);
+  add_wch(WACS_DEGREE);
   return s != 0;
 }
 EOF
   IFS=:
   for curses_inc in $curses_inc_list; do
+    IFS=:
     for curses_lib in $curses_lib_list; do
       unset IFS
       if compile_prog "$curses_inc" "$curses_lib" ; then
@@ -2955,6 +2957,9 @@ EOF
         break
       fi
     done
+    if test "$curses_found" = yes ; then
+      break
+    fi
   done
   unset IFS
   if test "$curses_found" = "yes" ; then
-- 
1.8.3.1

Re: [Qemu-devel] [PULL for-2.8 0/3] ui: bugfixes for gtk, curses and hid emulation.

[Stefan Hajnoczi]

[-- Attachment #1: Type: text/plain, Size: 1335 bytes --]

On Wed, Nov 09, 2016 at 03:38:40PM +0100, Gerd Hoffmann wrote:
>   Hi,
> 
> Here is the UI patch queue with three bugfixes,
> most importantly the cursesw configure fix.
> 
> please pull,
>   Gerd
> 
> The following changes since commit 207faf24c58859f5240f66bf6decc33b87a1776e:
> 
>   Merge remote-tracking branch 'pm215/tags/pull-target-arm-20161107' into staging (2016-11-07 14:02:15 +0000)
> 
> are available in the git repository at:
> 
> 
>   git://git.kraxel.org/qemu tags/pull-ui-20161109-1
> 
> for you to fetch changes up to ba60f2d18e976ef99238ebce019e26719f2b597c:
> 
>   Fix cursesw detection (2016-11-09 14:35:47 +0100)
> 
> ----------------------------------------------------------------
> ui: bugfixes for gtk, curses and hid emulation.
> 
> ----------------------------------------------------------------
> Peter Korsgaard (1):
>       hw/input/hid: support alternative sysrq/break scancodes for gtk-vnc
> 
> Samuel Thibault (1):
>       Fix cursesw detection
> 
> Thomas Huth (1):
>       ui/gtk: Fix build with older versions of gtk
> 
>  configure      | 7 ++++++-
>  hw/input/hid.c | 4 ++--
>  ui/gtk.c       | 3 ++-
>  3 files changed, 10 insertions(+), 4 deletions(-)
> 

Thanks, applied to my staging tree:
https://github.com/stefanha/qemu/commits/staging

Stefan

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 455 bytes --]