Update the X11 keycodes when keys are remapped.

Update the X11 keycodes when keys are remapped.

BUG=none
TEST=Used xmodmap to change the keycodes of F8/F9 keys. They continued to work to control volume.

[Evan Martin, 2011-05-17 16:44:46]

Do you expect to remap the keycodes at runtime?  I feel like for the platform
you're targeting this code might be unused, but I don't know your product
plans...

[sadrul, 2011-05-17 16:58:18]

On 2011/05/17 16:44:46, Evan Martin wrote:
> Do you expect to remap the keycodes at runtime?  I feel like for the platform
> you're targeting this code might be unused, but I don't know your product
> plans...

I think this may eventually be useful for non-GTK ChromeOS (this came up during
http://codereview.chromium.org/7011005/)

[Daniel Erat, 2011-05-17 18:33:16]

http://codereview.chromium.org/7019007/diff/1/chrome/browser/chromeos/system_...
File chrome/browser/chromeos/system_key_event_listener.cc (right):

http://codereview.chromium.org/7019007/diff/1/chrome/browser/chromeos/system_...
chrome/browser/chromeos/system_key_event_listener.cc:194: struct {
Mind unifying this with the code in the c'tor that initially grabs the keys, so
we don't have two copies of it?

http://codereview.chromium.org/7019007/diff/1/views/focus/accelerator_handler...
File views/focus/accelerator_handler_touch.cc (right):

http://codereview.chromium.org/7019007/diff/1/views/focus/accelerator_handler...
views/focus/accelerator_handler_touch.cc:133: Widget* widget = gwind ?
FindWidgetForGdkWindow(gwind) : NULL;
Mention this in the CL description too, assuming that it's a fix for some bug?

[sadrul, 2011-05-17 19:39:55]

http://codereview.chromium.org/7019007/diff/1/chrome/browser/chromeos/system_...
File chrome/browser/chromeos/system_key_event_listener.cc (right):

http://codereview.chromium.org/7019007/diff/1/chrome/browser/chromeos/system_...
chrome/browser/chromeos/system_key_event_listener.cc:194: struct {
On 2011/05/17 18:33:17, Daniel Erat wrote:
> Mind unifying this with the code in the c'tor that initially grabs the keys,
so
> we don't have two copies of it?

Done.

http://codereview.chromium.org/7019007/diff/1/views/focus/accelerator_handler...
File views/focus/accelerator_handler_touch.cc (right):

http://codereview.chromium.org/7019007/diff/1/views/focus/accelerator_handler...
views/focus/accelerator_handler_touch.cc:133: Widget* widget = gwind ?
FindWidgetForGdkWindow(gwind) : NULL;
On 2011/05/17 18:33:17, Daniel Erat wrote:
> Mention this in the CL description too, assuming that it's a fix for some bug?

Nope. This is for this CL. Until now, we have only intercepted keyboard and
mouse events, and for those, we have always had associated GdkWindow's. In this
case, however, for MappingNotify event, we get the XID of the root window, and
we don't have a GdkWindow associated with this.

[Evan Martin, 2011-05-17 19:42:00]

Just to be clear about my objection: unless we have a definite user for this
extra code, I suggest dropping it.  Does ChromeOS run xmodmap?

[Daniel Erat, 2011-05-17 19:57:28]

On 2011/05/17 19:42:00, Evan Martin wrote:
> Just to be clear about my objection: unless we have a definite user for this
> extra code, I suggest dropping it.  Does ChromeOS run xmodmap?

No, it uses XKB.  I'm assuming that GTK+ is XKB-aware, which means that we'll
probably see XkbMapNotify events instead of MappingNotify events (this could be
tested by changing the keyboard layout in Chrome OS).  See "12.1.2 Effects of
Xkb on MappingNotify Events" in http://www.xfree86.org/current/XKBlib.pdf.

(Like I mentioned in http://codereview.chromium.org/7011005/, this probably
isn't critical since I doubt we'll remap these keys.)