Bug 94279

Now the physical keyboard in the core protocol of "wl_keyboard", works on the principle of key codes from the library "xkbcommon". A virtual keyboard is implemented as an extension to the protocol: the client come characters in utf-8. But did you have to separate these 2 entities: physical and virtual keyboards? In the first case, the keyboard layout is given to the client, in the latter case - the compositor. What about the hieroglyphs? Compositor needs a clue, where exactly on the surface entering the symbol to displaying a menu select the desired character input via pinyin. But in addition to pinyin is required and directly write characters encoded in some encoding like utf-8. Key codes there is clearly no help, because even if you switch to "en-ru" layout weston-terminal eats up the next character, and "ctrl с" where "с" - russian character, completely blocks the ability of entering text. Weston-editor always writes to stdout "input language is en," although it is not.

Why initially it was impossible to give layouts to compositor, clients to give utf-8 characters and modifiers separately? Yes, bind the protocol to a single encoding may not seem right, but we all understand that in today's world means utf-8 after the chaos of single-byte encodings? In the result, we get guaranteed delivery to the client of that character, who wanted to send the user. As features could as wl_keyboard to send utf-8 characters from the microphone, hand gestures from a video camera or special devices for people with disabilities.