All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefan Weil <sw@weilnetz.de>
To: "Andreas Färber" <afaerber@suse.de>,
	"Kevin Wolf" <kwolf@redhat.com>,
	"Thebault, Remi" <remi.thebault@outlook.com>
Cc: Tim Hardeck <thardeck@suse.de>, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] alt-gr on Windows
Date: Thu, 01 Jan 2015 20:10:28 +0100	[thread overview]
Message-ID: <54A59BA4.2090700@weilnetz.de> (raw)
In-Reply-To: <54A574D4.5050306@suse.de>

Am 01.01.2015 um 17:24 schrieb Andreas Färber:
> Hi, Am 18.12.2014 um 12:55 schrieb Kevin Wolf:
>> Am 17.12.2014 um 01:11 hat Thebault, Remi geschrieben:
>>> This is not the first post on this topic, but I haven't seen any 
>>> solution about it. I tested so far linux guest on windows host and 
>>> the AltGr key is dead in the guest. (using git master branch) On 
>>> french keyboard, the keys to yield the bar "|" are alt-gr + 6. when 
>>> executing this combination on keyboard, Windows generates this: - 
>>> L-CTRL - R-ALT - 6 in Qemu (only digged gtk UI so far), pressing 
>>> alt-gr + 6 generates the following trace - L-CTRL - L-ALT <-- note 
>>> left here - 6 This comes from the Win32 call MapVirtualKey in gtk.c 
>>> that maps to scancodes without left/right distinction. Even when 
>>> sending the right alt to the guest, the alt-gr key remains dead 
>>> because of ctrl being virtually pressed. I found out however that if 
>>> R-ALT + 6 is sent without the ctrl key, the guest finally recognize 
>>> it and prints the bar, @, # and other [}{]. To make things easier, 
>>> Windows delivers the ctrl code before the alt code, so catching it 
>>> cleanly before delivery to the guest is probably tough. I could 
>>> however come to an easy and quick fix with sending the "ctrl up" 
>>> signal to the guest before the "r-alt down" is sent. My current code 
>>> do not handle all corner cases (eg: turbo mode) and only fixes the 
>>> gtk ui, but would such fix be accepted in the repo? Would this break 
>>> somehow the windows guest on windows host? 
>> CCing Stefan Weil, who is both the Windows maintainer and the author 
>> of commit 2777ccc5, which introduced the MapVirtualKey() call. As 
>> there is a special case for Alt Gr in the code, I suppose he had this 
>> working back then. From what I understand (which isn't much when it's 
>> about Windows), it seems very unlikely to me that the change would 
>> break anything that is working today; but you should probably give it 
>> some testing before posting a patch. 
> Tim and colleagues have been investigating some AltGr issues on Linux 
> / NoVNC as well, so it may well have been broken before Stefan's 
> commit. Regards, Andreas 


Indeed, when I wrote that commit, it fixed an AltGr issue. I spent the 
last weeks (well, not all the time, but some minutes) to restore my 
previous test scenario, but without success.

Remi's patch is a clear improvement of the current situation, but the 
problem is more complicated than one would think at a first glance.

I suggest calling MapVirtualKey only for those keys which don't need 
special handling, so it would be in the default case of the switch 
statement.

It looks like Alt-Ctrl is a valid alternative for pressing AltGr on 
Windows, so we have to take that into account, too.

Wine also needs special handling because it sends a single (different) 
key code instead of two key codes.

Regards
Stefan

  reply	other threads:[~2015-01-01 19:10 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-17  0:11 [Qemu-devel] alt-gr on Windows Thebault, Remi
2014-12-18 11:55 ` Kevin Wolf
2014-12-21 17:54   ` Thebault, Remi
2015-01-01 16:24   ` Andreas Färber
2015-01-01 19:10     ` Stefan Weil [this message]
2015-01-25 16:36       ` [Qemu-devel] [PATCH v2] " Thebault, Remi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=54A59BA4.2090700@weilnetz.de \
    --to=sw@weilnetz.de \
    --cc=afaerber@suse.de \
    --cc=kwolf@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=remi.thebault@outlook.com \
    --cc=thardeck@suse.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.