Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
357613002:
Gets correct KeyboardCode from XEvent for non-US layouts. (Closed)
DescriptionGets correct KeyboardCode from XEvent for non-US layouts.
Originally KeyboardCodeFromXKeyEvent() doesn't support non-US keyboard layouts.
It directly does 1-1 mapping from keysym to VKEY. To make it support non-US
keyboard, this cl uses the generated maps:
- ch0: vk
- ch0+sc: vk
- ch0+sc+ch1: vk
- ch0+sc+ch1+ch2: vk
The maps data is from Windows keyboard DLLs.
BUG=386066
TEST=Verified on Pixel device.
Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=281395
Patch Set 1 #Patch Set 2 : changed DefaultXKeysymFromHardwareKeycode to DefaultKeyboardCodeFromHardwareKeycode. #Patch Set 3 : fixed test failures due to unsorted MAP1. #
Total comments: 6
Patch Set 4 : nits per comments. #Patch Set 5 : fixed unit_tests failures. #Patch Set 6 : #Patch Set 7 : considering perf, only find in maps when keysym is not function/cursor/modifier/etc. key. #Patch Set 8 : updated the maps data, and make sure 2-bytes keysym to lookup in maps. #Patch Set 9 : fixed bugs in generator scripts and updated the maps data. #Patch Set 10 : #
Total comments: 26
Patch Set 11 : reviseded per comments. #Patch Set 12 : map KEY_RO to VKEY_OEM_102. #Patch Set 13 : #
Total comments: 1
Patch Set 14 : Fallback to find with (ch0+sc+ch1) if (ch0+sc+ch1+ch2) is not found in map3. #
Total comments: 4
Patch Set 15 : git cl format #
Messages
Total messages: 20 (0 generated)
Can you please help review this cl? Thanks Please let me know if you have questions of how the data is generated.
The try failures look related. Mind taking a look at those? On 2014/06/25 14:13:23, Shu Chen wrote: > Can you please help review this cl? Thanks > > Please let me know if you have questions of how the data is generated. Yes, where are these maps coming from?
Why are we expending effort on trying to patch up our generation of VKEY codes, which are inherently pretty broken, rather than on implementing the DOM3 Events "key" and "code" specifications? https://codereview.chromium.org/357613002/diff/40001/ui/events/keycodes/keybo... File ui/events/keycodes/keyboard_code_conversion_x.cc (right): https://codereview.chromium.org/357613002/diff/40001/ui/events/keycodes/keybo... ui/events/keycodes/keyboard_code_conversion_x.cc:46: // VKEY code should be VKEY_OEM_5 instead of VKEY_3. I think it's important to make clear in this comment what set of keys, or what set of circumstances, we're using each of the maps for. https://codereview.chromium.org/357613002/diff/40001/ui/events/keycodes/keybo... ui/events/keycodes/keyboard_code_conversion_x.cc:57: {0x0025, 0x35}, This table is basically impossible to sanity-check without either specifying the KeySym and VKEY values by name, or adding a comment following each to clarify which key it represents. https://codereview.chromium.org/357613002/diff/40001/ui/events/keycodes/keybo... ui/events/keycodes/keyboard_code_conversion_x.cc:422: // Gets correct VKEY code from XEvent is performed as the following steps: This doesn't necessarily find the correct VKEY, though, does it? It seems to assume that US is a good fallback for all layouts, for example.
The reasons to get correct VKEY code: 1) many web apps are using KeyboardEvent.keyCode instead of KeyboardEvent.key or KeyboardEvent.code. 2) Some Chrome browser behaviors are based on correct VKEY code. e.g. Ctrl+'+', Ctrl+'-', Ctrl+[0-9], Ctrl+Shift+'?', Ctrl+Alt+'/', etc. https://codereview.chromium.org/357613002/diff/40001/ui/events/keycodes/keybo... File ui/events/keycodes/keyboard_code_conversion_x.cc (right): https://codereview.chromium.org/357613002/diff/40001/ui/events/keycodes/keybo... ui/events/keycodes/keyboard_code_conversion_x.cc:46: // VKEY code should be VKEY_OEM_5 instead of VKEY_3. On 2014/06/26 02:10:42, Wez wrote: > I think it's important to make clear in this comment what set of keys, or what > set of circumstances, we're using each of the maps for. Done. https://codereview.chromium.org/357613002/diff/40001/ui/events/keycodes/keybo... ui/events/keycodes/keyboard_code_conversion_x.cc:57: {0x0025, 0x35}, On 2014/06/26 02:10:42, Wez wrote: > This table is basically impossible to sanity-check without either specifying the > KeySym and VKEY values by name, or adding a comment following each to clarify > which key it represents. Done. https://codereview.chromium.org/357613002/diff/40001/ui/events/keycodes/keybo... ui/events/keycodes/keyboard_code_conversion_x.cc:422: // Gets correct VKEY code from XEvent is performed as the following steps: On 2014/06/26 02:10:42, Wez wrote: > This doesn't necessarily find the correct VKEY, though, does it? It seems to > assume that US is a good fallback for all layouts, for example. It is necessary to find the correct VKEY, and US is NOT a good fallback for all layouts. There are 2 real P1 bugs I can tell are: 1) "setxkbmap "gb(extd)"" and then press CTRL+#, and it will be treated as CTRL+3. 2) "setxkbmap fr" and then press CTRL+è, and it does nothing but user expects CTRL+7. Both bugs are mentioned in crbug.com/386066.
I've made test green. Can you please take another look? Thanks On 2014/06/25 22:35:34, sadrul wrote: > The try failures look related. Mind taking a look at those? > > On 2014/06/25 14:13:23, Shu Chen wrote: > > Can you please help review this cl? Thanks > > > > Please let me know if you have questions of how the data is generated. > > Yes, where are these maps coming from?
Handing off to Gary to review this one.
Hi Gary, can you please take a look at this cl? Thanks To Sadrul, the code to generate the maps is at: https://cs.corp.google.com/#piper///depot/google3/experimental/users/shuchen/... 1) Use KbdDemo.exe to generate list.txt. 2) Use parse_maps.py to generate result.txt from list.txt. 3) The keysymdef.py is to generate mappings for comments of the maps.
https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... File ui/events/keycodes/keyboard_code_conversion_x.cc (left): https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:25: // etc. keys. So it is necessary to use XLookupString instead. This comment is useful and should be kept by the call to XLookupString. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... File ui/events/keycodes/keyboard_code_conversion_x.cc (right): https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:27: // They are the generated VKEY code maps for all possible Latin keyboard These are... https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:28: // layouts in Windows. And the maps are only for special letter keys exclude exclude -> excluding https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:43: // The reason of creating these maps is because a hard-coded mapping in ...reason for creating... https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:45: // e.g. in UK keyboard, the # key is located at BackSlash key position, and its It is not accurate to say that the '#'-key on a UK keyboard is "located at the Backslash key position" - it is located between the Quote and Enter keys (this physical key doesn't exist on a US keyboard). On Windows, it has the same VKEY as the '\'-key on a US keyboard (located above the Enter key - this key is found only on US keyboards). The US '\'-key and the UK '#'-key have different USB Usage IDs (and different DOM3 'code's), but they both map to VKEY_OEM_5 on Windows. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:426: // 8. If not found, fallback to find with the hardward code in US layout. hardware https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:790: // This table covers the core 105-key keyboard. This comment should be removed because it is not accurate. The table contains entries that cover 101, 102 (aka 105), 103, 104 and 106 keyboards. See http://www.w3.org/TR/DOM-Level-3-Events-code/#keyboard-101 https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:888: VKEY_UNKNOWN, // 0x61: KEY_RO Romaji VKEY_DBE_ROMAN? Also, KEY_RO looks like a typo. I know that the KeyboardCodeFromXKeysym table didn't handle these XK_ values, but we should try to find appropriate values while we're editing this table. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:889: VKEY_UNKNOWN, // 0x62: KEY_KATAKANA Katakana VKEY_DBE_KATAKANA? https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:890: VKEY_UNKNOWN, // 0x63: KEY_HIRAGANA Hiragana VKEY_DBE_HIRAGANA? https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:892: VKEY_UNKNOWN, // 0x65: KEY_KATAKANAHIRAGANA Hiragana_Katakana ? https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:917: VKEY_UNKNOWN, // 0x7E: KEY_KPPLUSMINUS plusminus ? https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:923: VKEY_UNKNOWN, // 0x84: KEY_YEN yen Having the Yen key map to Unknown concerns me.
https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... File ui/events/keycodes/keyboard_code_conversion_x.cc (left): https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:25: // etc. keys. So it is necessary to use XLookupString instead. On 2014/07/01 00:07:42, garykac wrote: > This comment is useful and should be kept by the call to XLookupString. Done. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... File ui/events/keycodes/keyboard_code_conversion_x.cc (right): https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:27: // They are the generated VKEY code maps for all possible Latin keyboard On 2014/07/01 00:07:41, garykac wrote: > These are... Done. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:28: // layouts in Windows. And the maps are only for special letter keys exclude On 2014/07/01 00:07:41, garykac wrote: > exclude -> excluding Done. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:43: // The reason of creating these maps is because a hard-coded mapping in On 2014/07/01 00:07:41, garykac wrote: > ...reason for creating... Done. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:45: // e.g. in UK keyboard, the # key is located at BackSlash key position, and its On 2014/07/01 00:07:42, garykac wrote: > It is not accurate to say that the '#'-key on a UK keyboard is "located at the > Backslash key position" - it is located between the Quote and Enter keys (this > physical key doesn't exist on a US keyboard). On Windows, it has the same VKEY > as the '\'-key on a US keyboard (located above the Enter key - this key is found > only on US keyboards). > > The US '\'-key and the UK '#'-key have different USB Usage IDs (and different > DOM3 'code's), but they both map to VKEY_OEM_5 on Windows. Done. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:426: // 8. If not found, fallback to find with the hardward code in US layout. On 2014/07/01 00:07:41, garykac wrote: > hardware Done. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:790: // This table covers the core 105-key keyboard. On 2014/07/01 00:07:42, garykac wrote: > This comment should be removed because it is not accurate. The table contains > entries that cover 101, 102 (aka 105), 103, 104 and 106 keyboards. > > See http://www.w3.org/TR/DOM-Level-3-Events-code/#keyboard-101 Done. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:888: VKEY_UNKNOWN, // 0x61: KEY_RO Romaji On 2014/07/01 00:07:41, garykac wrote: > VKEY_DBE_ROMAN? > > Also, KEY_RO looks like a typo. > > I know that the KeyboardCodeFromXKeysym table didn't handle these XK_ values, > but we should try to find appropriate values while we're editing this table. KEY_RO is not a typo, please see https://code.google.com/p/chromium/codesearch#chromium/usr/include/linux/inpu... I've explicitly renamed it as VKEY_UNSUPPORTED. If we're editing this table in the future, the author should be aware of it. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:889: VKEY_UNKNOWN, // 0x62: KEY_KATAKANA Katakana On 2014/07/01 00:07:42, garykac wrote: > VKEY_DBE_KATAKANA? Ditto. And VKEY_DBE_KATAKANA is not defined in chromium. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:890: VKEY_UNKNOWN, // 0x63: KEY_HIRAGANA Hiragana On 2014/07/01 00:07:41, garykac wrote: > VKEY_DBE_HIRAGANA? Ditto. And VKEY_DBE_HIRAGANA is not defined in chromium. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:892: VKEY_UNKNOWN, // 0x65: KEY_KATAKANAHIRAGANA Hiragana_Katakana On 2014/07/01 00:07:42, garykac wrote: > ? Ditto. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:917: VKEY_UNKNOWN, // 0x7E: KEY_KPPLUSMINUS plusminus On 2014/07/01 00:07:42, garykac wrote: > ? Ditto. https://codereview.chromium.org/357613002/diff/160001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:923: VKEY_UNKNOWN, // 0x84: KEY_YEN yen On 2014/07/01 00:07:41, garykac wrote: > Having the Yen key map to Unknown concerns me. Done. Changed it to VKEY_OEM_5 per https://developer.mozilla.org/en-US/docs/Web/API/KeyboardEvent.keyCode
lgtm This seems fine, but it's hard to verify that all the mappings are correct. Are there any tests anywhere for these tables? For example, one that would verify that the UK #~ key now produces the correct VKEY? https://codereview.chromium.org/357613002/diff/210001/ui/events/keycodes/keyb... File ui/events/keycodes/keyboard_code_conversion_x.cc (right): https://codereview.chromium.org/357613002/diff/210001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:797: // http://download.microsoft.com/download/1/6/1/161ba512-40e2-4cc9-843a-923143f3... The microsoft.com link doesn't work for me.
The KeyboardCodeFromXKeyEvent methods uses XLookupString. Do you know a feasible way to change different XKB map on X11 server for tests? Or override XLookupString for tests? I've manually verified # key on UK keyboard and Ctrl+[0-9] on FR keyboard. I've also made a python script to verify that each item in the original map from DLLs on Windows can be found in MAP0-MAP3, except 13 conflicts which cannot be solved by (ch0,sc,ch1,ch2). I will update the generator code and all scripts to internal code base later. Thanks, Shu 0x0060 0x007E 0x0031 TLDE 0xDF KBDAZEL.DLL 0x0027 0x003F 0xF001 AE11 0xBF KBDCR.DLL 0x00F6 0x00D6 0xF000 AC10 0xBA KBDEST.DLL 0x00E4 0x00C4 0xF001 AC11 0xBF KBDEST.DLL 0x00FC 0x00DC 0xF000 AE11 0xBD KBDHU1.DLL 0x0060 0x007E 0xF000 TLDE 0xDC KBDLT2.DLL 0x012F 0x012E 0xF000 AD11 0xDD KBDLT2.DLL 0x0027 0x0040 0xF000 AC11 0xDE KBDMLT48.DLL 0x0023 0x007E 0xF000 BKSL 0xDC KBDMLT48.DLL 0x0027 0x002A 0xF001 AE12 0xBF KBDPL.DLL 0x002B 0x003F 0xF000 AE11 0xBD KBDRO.DLL 0x003D 0x0025 0xF001 AE11 0xBF KBDSL.DLL 0x003D 0x0025 0xF001 AE11 0xBD KBDSL1.DLL On 2014/07/02 23:45:31, garykac wrote: > lgtm > > This seems fine, but it's hard to verify that all the mappings are correct. > > Are there any tests anywhere for these tables? For example, one that would > verify that the UK #~ key now produces the correct VKEY?
sadrul@, do you have comments on this cl? Your lgtm is required for changes in ui/events/test/events_test_utils_x11.cc. Thanks, Shu
On 2014/06/27 02:49:11, Shu Chen wrote: > Hi Gary, can you please take a look at this cl? Thanks > > To Sadrul, the code to generate the maps is at: > https://cs.corp.google.com/#piper///depot/google3/experimental/users/shuchen/... > > 1) Use KbdDemo.exe to generate list.txt. > 2) Use parse_maps.py to generate result.txt from list.txt. > 3) The keysymdef.py is to generate mappings for comments of the maps. I think it'd be good to have these scripts reviewed + checked into the tree. So the next person working on this has something to work with. Do you mind owning a bug for this so this doesn't get lost? Also, please have the CL go through 'git cl format', and update the CL description with a little more detail. LGTM for ui/events/test/ https://codereview.chromium.org/357613002/diff/230001/ui/events/keycodes/keyb... File ui/events/keycodes/keyboard_code_conversion_x.cc (right): https://codereview.chromium.org/357613002/diff/230001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:400: {0x03F9, 0x2F, 0x03D9, 0x01DE, 0xBA}, // XK_uogonek+AC10+XK_Uogonek+XK_Tcedilla: VKEY_OEM_1 80+ cols here https://codereview.chromium.org/357613002/diff/230001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:405: { { in the previous line
On 2014/07/04 05:58:39, sadrul wrote: > On 2014/06/27 02:49:11, Shu Chen wrote: > > Hi Gary, can you please take a look at this cl? Thanks > > > > To Sadrul, the code to generate the maps is at: > > > https://cs.corp.google.com/#piper///depot/google3/experimental/users/shuchen/... > > > > 1) Use KbdDemo.exe to generate list.txt. > > 2) Use parse_maps.py to generate result.txt from list.txt. > > 3) The keysymdef.py is to generate mappings for comments of the maps. > > I think it'd be good to have these scripts reviewed + checked into the tree. So > the next person working on this has something to work with. Do you mind owning a > bug for this so this doesn't get lost? > > Also, please have the CL go through 'git cl format', and update the CL > description with a little more detail. > > LGTM for ui/events/test/ No problem. I will create a separated cl to directly generate the maps data when compiling.
https://codereview.chromium.org/357613002/diff/230001/ui/events/keycodes/keyb... File ui/events/keycodes/keyboard_code_conversion_x.cc (right): https://codereview.chromium.org/357613002/diff/230001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:400: {0x03F9, 0x2F, 0x03D9, 0x01DE, 0xBA}, // XK_uogonek+AC10+XK_Uogonek+XK_Tcedilla: VKEY_OEM_1 On 2014/07/04 05:58:38, sadrul wrote: > 80+ cols here Done. https://codereview.chromium.org/357613002/diff/230001/ui/events/keycodes/keyb... ui/events/keycodes/keyboard_code_conversion_x.cc:405: { On 2014/07/04 05:58:38, sadrul wrote: > { in the previous line Done.
The CQ bit was checked by shuchen@chromium.org
CQ is trying da patch. Follow status at https://chromium-status.appspot.com/cq/shuchen@chromium.org/357613002/250001
FYI, CQ is re-trying this CL (attempt #1). The failing builders are: ios_rel_device on tryserver.chromium (http://build.chromium.org/p/tryserver.chromium/builders/ios_rel_device/builds...)
Message was sent while issue was closed.
Change committed as 281395
Message was sent while issue was closed.
On 2014/07/04 11:48:53, I haz the power (commit-bot) wrote:
> Change committed as 281395
This broke the build on my 64 bits Archlinux with GCC 4.8 :
../../ui/events/keycodes/keyboard_code_conversion_x.cc: In function
‘ui::KeyboardCode ui::KeyboardCodeFromXKeyEvent(XEvent*)’:
../../ui/events/keycodes/keyboard_code_conversion_x.cc:497:25: error: narrowing
conversion of ‘(keysym & 65535ul)’ from ‘KeySym {aka long unsigned int}’ to
‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
MAP0 key0 = {keysym & 0xFFFF, 0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:502:25: error: narrowing
conversion of ‘(keysym & 65535ul)’ from ‘KeySym {aka long unsigned int}’ to
‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
MAP1 key1 = {keysym & 0xFFFF, xkey.keycode, 0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:502:50: error: narrowing
conversion of ‘xkey.XKeyEvent::keycode’ from ‘unsigned int’ to ‘uint8 {aka
unsigned char}’ inside { } is ill-formed in C++11 [-Werror=narrowing]
MAP1 key1 = {keysym & 0xFFFF, xkey.keycode, 0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:510:25: error: narrowing
conversion of ‘(keysym & 65535ul)’ from ‘KeySym {aka long unsigned int}’ to
‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
MAP2 key2 = {keysym & 0xFFFF, xkey.keycode, keysym_shift & 0xFFFF, 0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:510:73: error: narrowing
conversion of ‘xkey.XKeyEvent::keycode’ from ‘unsigned int’ to ‘uint8 {aka
unsigned char}’ inside { } is ill-formed in C++11 [-Werror=narrowing]
MAP2 key2 = {keysym & 0xFFFF, xkey.keycode, keysym_shift & 0xFFFF, 0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:510:62: error: narrowing
conversion of ‘(keysym_shift & 65535ul)’ from ‘KeySym {aka long unsigned int}’
to ‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
MAP2 key2 = {keysym & 0xFFFF, xkey.keycode, keysym_shift & 0xFFFF, 0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:519:25: error: narrowing
conversion of ‘(keysym & 65535ul)’ from ‘KeySym {aka long unsigned int}’ to
‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
MAP3 key3 = {keysym & 0xFFFF, xkey.keycode, keysym_shift & 0xFFFF,
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:520:42: error: narrowing
conversion of ‘xkey.XKeyEvent::keycode’ from ‘unsigned int’ to ‘uint8 {aka
unsigned char}’ inside { } is ill-formed in C++11 [-Werror=narrowing]
keysym_altgr & 0xFFFF, 0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:519:62: error: narrowing
conversion of ‘(keysym_shift & 65535ul)’ from ‘KeySym {aka long unsigned int}’
to ‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
MAP3 key3 = {keysym & 0xFFFF, xkey.keycode, keysym_shift & 0xFFFF,
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:520:31: error: narrowing
conversion of ‘(keysym_altgr & 65535ul)’ from ‘KeySym {aka long unsigned int}’
to ‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
keysym_altgr & 0xFFFF, 0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:528:25: error: narrowing
conversion of ‘(keysym & 65535ul)’ from ‘KeySym {aka long unsigned int}’ to
‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
MAP3 key4 = {keysym & 0xFFFF, xkey.keycode, keysym_shift & 0xFFFF, 0xFFFF,
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:529:19: error: narrowing
conversion of ‘xkey.XKeyEvent::keycode’ from ‘unsigned int’ to ‘uint8 {aka
unsigned char}’ inside { } is ill-formed in C++11 [-Werror=narrowing]
0};
^
../../ui/events/keycodes/keyboard_code_conversion_x.cc:528:62: error: narrowing
conversion of ‘(keysym_shift & 65535ul)’ from ‘KeySym {aka long unsigned int}’
to ‘uint16 {aka short unsigned int}’ inside { } is ill-formed in C++11
[-Werror=narrowing]
MAP3 key4 = {keysym & 0xFFFF, xkey.keycode, keysym_shift & 0xFFFF, 0xFFFF,
^
cc1plus: all warnings being treated as errors
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
