[PATCH 1/2] Add more keyboards for the RDP compositor

[Daniel Stone]

Hi,

On 11 April 2014 21:49, Bill Spitzak <spitzak at gmail.com> wrote:
>
> On 04/11/2014 01:10 PM, Hardening wrote:
>>
>> 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.
>>
>>  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.
>

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.)


> 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.
>

Sounds like an extremely roundabout way of doing it.


> 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!
>

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.


> 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.
>
> 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!
>
> 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.
>
> 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.
>
> 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.


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.

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.

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.

Cheers,
Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20140414/26639dae/attachment.html>