Your message dated Fri, 10 Jun 2016 01:14:33 -0400
with message-id
<CANTw=MN-8nS7gB9JioToYWQjOLJO77WyY0Ug=ge7yoskhzl...@mail.gmail.com>
and subject line re: keyboard input
has caused the Debian Bug report #826238,
regarding chromium: International keyboard input completely broken: can not use
AltGr as compose, dead key or layout switch key
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact [email protected]
immediately.)
--
826238: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=826238
Debian Bug Tracking System
Contact [email protected] with problems
--- Begin Message ---
Package: chromium
Version: 37.0.2062.120-1~deb7u1
Severity: normal
International keyboard input completely broken: can not use AltGr as
compose, dead key or layout switch key.
As an example, it is too difficult for me to type anything in chromium:
i am a developer and need to mix text on native message with terms in
Latin encoding, if i try to switch layout then input focus lost (menu
selected). All other applications works as expected.
This bug fixed in upstream.
Chromium Issue #402320:
https://groups.google.com/a/chromium.org/forum/#!
topic/chromium-bugs/RFGH5-C3-S4
Upstream fix:
https://chromium.googlesource.com/chromium/src/+/83c2b41f1a06ca226a05edf0602d5c6efea32a8b%5E%21/#F0
(to patch Debian version replace "xkey->keycode" with "xkey.keycode").
Package was rebuild with slightly modified upstream patch (attached as
no-fallback-hw-codes.patch) and tested. Fix helps in case on AltGr as
layout toggle key.
-- System Information:
Debian Release: 7.10
APT prefers oldstable-updates
APT policy: (500, 'oldstable-updates'), (500, 'oldstable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 3.2.0-4-amd64 (SMP w/4 CPU cores)
Locale: LANG=ru_RU.UTF-8, LC_CTYPE=ru_RU.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
From 83c2b41f1a06ca226a05edf0602d5c6efea32a8b Mon Sep 17 00:00:00 2001
From: yukishiino <[email protected]>
Date: Tue, 7 Oct 2014 14:56:31 +0000
Subject: [PATCH] linux: Do not fallback to the hardware keycodes for modifiers.
Previously Chrome would fall-back to deriving VKEY values directly from the
hardware keycode if it was unable to derive a value from the X KeySym. While
that is necessary for e.g. providing valid VKEYs for printable character
keys under non-Latin keyboard layouts (such as Hebrew or Arabic), it had the
side-effect of causing KeySyms with no VKEY equivalent to be mapped to
incorrect meanings.
In issue 402320, for example, the ISO_Level3_Latch KeySym has no VKEY
equivalent, so should result in VKEY_UNKNOWN, but was instead having an
incorrect VKEY derived from the X11 keycode instead.
Note that there is no clear reason why we don't allow the modifier keys to
fall back to the hardware keycode while we allow the printable character
keys to fall back. It's just close to what users expect. There could be a
problem if a keyboard layout had a composition character on Control + Ч
(which falls back to VKEY_X). Users cannot type that composition character
because a Cut accelerator triggers instead.
This approach is a heuristic designed to approximate the VKEY values that a
Windows system would generate, to ensure compatibility.
BUG=402320
TEST=Done manually (assigning ISO_Level3_Latch to key code 108).
Review URL: https://codereview.chromium.org/611993002
Cr-Commit-Position: refs/heads/master@{#298478}
diff --git a/ui/events/keycodes/keyboard_code_conversion_x.cc b/ui/events/keycodes/keyboard_code_conversion_x.cc
index 4e0882b..daba8115 100644
--- a/ui/events/keycodes/keyboard_code_conversion_x.cc
+++ b/ui/events/keycodes/keyboard_code_conversion_x.cc
@@ -545,8 +545,11 @@
}
keycode = KeyboardCodeFromXKeysym(keysym);
- if (keycode == VKEY_UNKNOWN)
+ if (keycode == VKEY_UNKNOWN && !IsModifierKey(keysym)) {
+ // Modifier keys should not fall back to the hardware-keycode-based US
+ // layout. See crbug.com/402320
keycode = DefaultKeyboardCodeFromHardwareKeycode(xkey.keycode);
+ }
return keycode;
}
smime.p7s
Description: S/MIME cryptographic signature
--- End Message ---
--- Begin Message ---
version: 38.0.2125.101-1
--- End Message ---