Re: XKB Patch

I have a feeling that I'm getting terribly misunderstood. In case my wording
wasn't correct, I was referring to "XKB keynames" with the words "symbolic
key names".

Ilya, I agree with you except for using the XKB API. Let me explain what my
code is doing:

I made a perl script that reads the keycode -> XKB keynames. I understand
the power of XKB key names, they provide a hardware independent naming for
keys, somehow like virtual key codes. That is what we want to use, and not
key syms. The reason why I am converting these maps to a different format is
because XKB key names have to be mapped to virtual key codes so that they
can be used more conveniently with rdesktop. So, my perl script exports part
of the XKB maps to keycodes -> virtual key codes maps that are ready to be
used by rdesktop, completely independent of an XKB-aware X server.

When we initially discussed this a few months ago, many people have
expressed their concern that rdesktop should remain compatible with systems
that do not have XKB. Instead of having one way for XKB-aware systems and a
different one for those that have, I thought of a consistent one that would
work for both. What I came up with was the idea of using only a small part
of the maps of XKB in an easy to use format, and that I would write my own
parsing functions to load it. This way, a system without XKB would be able
to use my code without any problem, because we simply aren't depending on
XKB or anything from the XKB API.

So, to clarify the obvious misunderstandings:

I am NOT adding any dependency on XKB, or using the XKB API or anything.

I am using the XKB key names, the names that make abstraction of the
hardware itself to bring consistent naming of the keys. These are mapped to
virtual key codes when the key maps are exported from the XKB configuration
database. These new maps should then be included with rdesktop, they really
don't take space and it allows us to support systems without XKB.

When rdesktop starts, it tries to detect the current keyboard type, and also
the current keyboard layout. Keyboard layout detection is only used to
announce to the server what keyboard layout to use. Keyboard _type_
detection is used to load the corresponding keycode -> virtual key code map.

So, once the keycode -> virtual key code map is loaded, rdesktop is able to
map each keystroke directly to a virtual key code. The virtual key code is
then mapped to a scan code that is sent. I suggest you take a look at my
source code, especially keyboard.h and xkbkeymap.c, it should clarify
things.

On Fri, May 15, 2009 at 10:49 AM, Ilya Konstantinov <[email protected]>wrote:

> On Fri, May 15, 2009 at 5:34 PM, Peter Åstrand <[email protected]> wrote:
>
>>
>> Guys, I don't know why you insist on completely *missing* the one main
>>> thing which XKB gives you:reliable (runtime)
>>> [ X11 keysym -> hardware key ] mapping
>>>
>>
>> Well, basically I don't know how XKB works or what kind of capabilites it
>> has. I'm planning to try to learn it, but digging through the 155 pages XKB
>> protocol specification doesn't sound like much fun...
>
>
> So there, I'm giving you a rundown :)
>
> In any case, I wouldn't start with the spec. The spec is the API reference
> when using libXkb. Just to understand the architecture, I'd read Ivan
> Pascal's doc:
> http://pascal.tsu.ru/en/xkb/internals.html
>
>  Instead, you choose to focus on locales, languages, keyboard names and
>>> variants and whatnot. Why? There is no need to know whether the keyboard is
>>> English or Lithuanian,
>>>
>>
>> Perhaps not for sending a suitable scancode, but one needs to tell the
>> remote desktop which keymap to use.
>
>
> Yes, you're referring to the "secondary keyboard language LCID" in the RDP
> init packet.
> You can do this through heuristics, e.g. by parsing the _XKB_RULES_NAMES
> root window property. (You don't need the XKB API for that.)
> Without XKB, you can determine it from the locale.
>
> It's a best-effort guess thing, really. It has nothing to do with keyboard
> mapping; it's just about trying to pass a piece of the local user
> preferences to the remote machine, to provide a more familiar desktop on the
> remote machine.
>
>  Simply do this:
>>> 1. Read the XKB *keyname* -> X11 keycode (NOT keysym) mapping
>>> (dynamically from the server - use the XKB API)
>>> 2. Reverse it (make it a keycode->keyname map)
>>> 3. Write a mapping (even statically, in code!) which maps XKB *keynames*
>>> to AT (RDP) scancodes. This mapping should
>>> be used instead of the rdesktop keymap facility.
>>>
>>
>> So basically, you want the rdesktop keymaps to map "XKB keynames to
>> scancodes", instead of "keysyms to scancodes"? I guess that's possible. But
>> what should rdesktop do with Xservers that doesn't support XKB?
>
>
> When the XKB extension is not available, we should fall back to the
> existing facility (the one which uses rdesktop keymap files).
>

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables 
unlimited royalty-free distribution of the report engine 
for externally facing server and web deployment. 
http://p.sf.net/sfu/businessobjects

_______________________________________________
rdesktop-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/rdesktop-devel