<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 11 April 2014 21:49, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="">
On 04/11/2014 01:10 PM, Hardening wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I have heard that in some cases windows layouts (which are also RDP ones) don't match exact the XKB ones :(. So the surprises can come when using mstsc against a linux host.<br>
<br>
</blockquote></div>
I have had it fail between different versions of Linux with very similar keyboards. At work they used SUSE and at home I had Ubuntu 12.04. When I NX from home, every single function key was messed up. Up arrow was PrintScreen, for instance.<br>
</blockquote><div><br></div><div>This is a mismatch between the kbd and evdev drivers, which would be fine if people actually used the XKB maps the server sent, and didn't attempt to reset it to something that didn't make sense.  (Clients cannot change the keymap in Wayland, so no problem there.)</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Somebody at work had fortunately done all the hard work, which basically involved using xev to see what keycode it coughed up when you hit keys and making an xmodmap entry for every one of these. This table worked for me.<br>
</blockquote><div><br></div><div>Sounds like an extremely roundabout way of doing it.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Then they updated to Centos at work, and it *still* failed, but with an all-new and different set of keysyms. I only managed to fix the arrows and just lived with it, but this is plainly a totally unacceptable situation for user friendliness!<br>
</blockquote><div><br></div><div>Yes, which is why we worked for quite some time to fix all of those bugs which occurred both in the X server and GNOME.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

I also used the OS/X NX at home to the same machine. It had a different (smaller) set of screwed up function keys. And different, so I could not automatically run xmodmap on detecting NX. You would think it would be worse when you are not running X but in fact it was somewhat better. In particular the arrows did work.<br>

<br>
Note that the *keysym* after it worked was absolutely identical on both ends. The only difference in the keyboards is my home one lacked a "windows" key, which should have had ONLY the effect that I could not type the Windows key!<br>

<br>
In Wayland I have also seen bugs where the input method disagrees with the client about what a key decodes to, and this is with the *same* keyboard on the *same* machine! I think it would be a good idea to make this impossible.<br>

<br>
I recommend that key events be enhanced to have 2 keysyms in addition to the hardware scan codes. One is the "which physical button on the keyboard" and the other is "effective keysym including shift state". It is allowed to put a special "I don't know" value in any of these, and clients are expected to figure out what they can from the "known" parts. A client may run xkb decoding if it wants, but the compositor can also do it in one place, so at least everything will match.<br>

<br>
You also need to look into allowing the input method to run on the local machine, thus the communication of text from the input method must be sent.</blockquote><div><br></div><div>Given your habit of talking in the theoretical and totally disregarding what already exists, I'm going to assume you've never actually looked at the text / input method interface which has been in Weston for nigh on two years now, and just give you the pithy answer that it exists, and use it if you want.  But it doesn't cover every usecase (for example, it just cannot be made to work with shortcuts, even given your suggested interface), so wl_keyboard exists for that reason and will continue to exist to the end of days, because sometimes you really, really, really do need a keycode-based interface.</div>
<div><br></div><div>Rest assured we did spend more than 30 seconds thinking about this; just because the implications and tradeoffs are not immediately obvious to you, doesn't mean they don't exist.</div><div><br>
</div><div>Yet again, it would be amazing if you had the decency to look at what exists and maybe even came up with a prototype, rather than throwing out blithe 'oh, everything would work if ...' assertions on the list which are either not true, or run contrary to design decisions which had already been made, potentially misleading people who aren't aware of the status and your history of doing this, thus wasting their time and everyone else's.</div>
<div><br></div><div>Cheers,</div><div>Daniel</div></div></div></div>