rdesktop

I have not tried to grok this discussion, but I would like to add an 
observation / idea:

Rdesktop currently sends keyboard scan codes - 
http://msdn.microsoft.com/en-us/library/cc240584%28PROT.10%29.aspx .

Perhaps unicode scan codes could be sent instead - 
http://msdn.microsoft.com/en-us/library/cc240585%28PROT.10%29.aspx and 
http://msdn.microsoft.com/en-us/library/cc240593%28PROT.10%29.aspx . 
That approach might not work and will probably have other disadvantages, 
but perhaps it is worth considering ...

/Mads

That's probably a new capability. We should check it out, but:1) It doesn't
cover all keys, only those keys which produce characters (e.g. not including
F1),
2) mstsc transmits the physical keys, without regard to the local keyboard
mode. I think we should do the same, at least by default.

Otherwise, sure, it should be implemented :)

On Fri, May 15, 2009 at 5:55 PM, Mads Kiilerich <mads@...> wrote:

> I have not tried to grok this discussion, but I would like to add an
> observation / idea:
>
> Rdesktop currently sends keyboard scan codes -
> http://msdn.microsoft.com/en-us/library/cc240584%28PROT.10%29.aspx .
>
> Perhaps unicode scan codes could be sent instead -
> http://msdn.microsoft.com/en-us/library/cc240585%28PROT.10%29.aspx and
> http://msdn.microsoft.com/en-us/library/cc240593%28PROT.10%29.aspx .
> That approach might not work and will probably have other disadvantages,
> but perhaps it is worth considering ...
>
> /Mads
>
>
>
> ------------------------------------------------------------------------------
> 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
> rdesktop-devel@...
> https://lists.sourceforge.net/lists/listinfo/rdesktop-devel
>

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 <future@...:

> On Fri, May 15, 2009 at 5:34 PM, Peter Åstrand <astrand@...> 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).
>

On Fri, 15 May 2009, Ilya Konstantinov wrote:

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

I'm referring to the g_keylayout variable in rdesktop, which defaults to 
0x409, and is otherwise set by using the "map" keyword in keymap files. It 
is also sent in sec_out_mcs_data, under the section:

  	/* Client information */
 	out_uint16_le(s, SEC_TAG_CLI_INFO);

This information tells the RDP server which keymap to use, ie how to 
interpret RDP scancodes.

Are you sure we are talking about the same thing? "secondary keyboard" 
sounds strange to me.


> When the XKB extension is not available, we should fall back to the 
> existing facility (the one which uses rdesktop keymap files).

In other words: Lots of pain, no gain. If we can't get rid of the current 
implementation nor the keymaps, it's going to be a *lot* of work for 
basically no value.


Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

On Fri, 15 May 2009, Marc-André Moreau wrote:

> 1) Re-using the numbers you have said, we currently have about 40 
> keymaps on a total of 120 possible keymaps that would constitute a 
> complete set of keymaps. 40 is still one third of 120, so we're not even 
> halfway done in order to bring full support for every keyboard layout.

True if you are just looking at the number or languages, but if you 
instead look at which countries and users that are actually using 
rdesktop, I would say that, in practice, we are covering almost all users 
and territories. We don't hear complains about missing keymaps from 2/3 of 
our users, right?


> I understand that if we go on a case by case basis, adding keymaps for 
> whatever keyboard layout someone needs, it does not require much effort. 
> The problem is that not everybody using an unsupported keyboard layout 
> would bother submitting a bug report, or getting to know rdesktop better 
> in order to write a new keymap and then submit it. Less common keyboard 
> layouts are most likely to remain unsupported. Also, even if the 
> majority of the keymaps currently work well, it may happen that someone 
> finds a bug in it and again it is no big deal to fix it. However, this 
> work of adding keymaps and maintaining them on an on-demand basis as 
> people find that their keyboard layout is unsupported or broken could be 
> solved using a "one for all" solution. That's why I thought of XKB, 
> because they already take care of doing that job.

I agree, in principle it's better if we can avoid having "our own" 
keymaps. I'm just concerned that this will in practice be very 
complicated. But I would be happy if you could prove that I'm wrong.


> You have mentioned that XKB has a lot of bugs. I have taken a look at the bug reports for xkb:
> https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=xke
> yboard-config&content=
> 
> And most of the bugs submitted are minor or cover aspects of the data base that we wouldn't even be using (such as
> the symbolic key name to keysym translation). Also, if we bother doing the maintenance work for our own set of
> keymaps, it would take just as much efforts to submit a bug report to XKB instead, and fix it on our side. We would
> benefit from that, and XKB would benefit from us (if we find bugs in their database).

Yes, squashing bugs in the upstream XKB database is better than fixing our 
own keymaps, I agree, if we are just talking about the XKB data base.

However, if we are talking about using the runtime XKEYBOARD extension as 
well, like Ilya Konstantinov suggests, we might suffer from many other 
bugs.

Believe it or not, but the X.Org keyboard handling and input system is not 
at all stable, it's in more flux than ever. Eventually it might be very 
nice with MPX and everything, but the fact is that today, there are 
numerous problems both with XKB as well as the classical events.


> Before going further, I need to explain more in depth the major differences between my method and the current one:

Wow, that was a lot of text...


> So, to summarize:
... 
> Even if I'm using XKB as a basis to export new keymaps using my perl script, we really aren't doing anything related
> to XKBlib or using any functions from it. The keycode -> virtual keycode -> scan code mapping is all done using my
> code. We're not doing anything complex here. The only bugs that could affect us related to XKB would be a bug in the
> keycode -> symbolic key code maps. My mapping of symbolic key codes to virtual key codes in my perl script is as
> complete as I could make it. If a bug is found in my perl script, it is trivial to fix and re-export the database.

A quick summarize from my point of view: I'm positive to try to use the 
information in the XKB database. The idea of generating keymaps from it 
using a perl script or similar is nice. This way, however, we should in 
principle be able to keep the current keyboard implementation as-is. We 
could add minor enhancements say trying to detect the keyboard layout 
using XKB if available and things like that, but this would be small, 
independent enhancements that will work with the existing keymap format 
and existing keymaps.

Is there any reason why this approach cannot be used?

Patches must be small and reasonable atomic if I should be able to accept 
them with good confidence. I've downloaded your modified version and 
unpacked it over an existing rdesktop working copy, and the result is a 
"diff" which is 2693 lines long, and I haven't even included the "xkb" 
subdirectory. This is a lot. Small is beautiful.


Regards, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

You should find a perl script called xkb.pl in the xkb folder in my patch.
To try it, all you have to do is download the latest version of the xkb
configuration database here:
http://xlibs.freedesktop.org/xkbdesc/xkeyboard-config-1.5.tar.bz2

Copy the perl script in the root of the directory of maps, and then run it.
The script will generate new keycode -> virtual keycode maps in a "xkb" sub
directory. You may also use the existing maps from your XKB installation if
you have it installed.

The majority of new lines of source code is made of macro definitions and
arrays of structures used for mapping. Most of the actual code that isn't
made out of definitions is in xkbkeymap.c.

The reason why we can't make a perl script that will export keymaps in the
current format from the XKB configuration database is because it is much
more easier and efficient to map keycodes -> virtual key codes instead of
doing key sym -> keycode -> virtual key code. key syms are already mapped
according to a keyboard layout, and we don't want to deal with that because
it all gets messy when we start considering modifier keys and dead keys. For
instance, when you consider key sym, a dead key on a particular keyboard
layout would for instance map to dead_eacute. With the current keymaps, this
would be mapped to a particular key and then sent, and then you have to make
a keymap that will be able to do that for every keyboard layout. When basing
ourselves on keycodes, you don't deal with that, you just map it directly to
a scan code and the server takes care of doing the mapping according to its
own keyboard layout.

About depending on buggy XKB API, well, my code is made so that it doesn't
depend on XKB API at all. The only thing we are considering here is a part
of the maps from the XKB configuration database, that serves as a basis to
export our set of keycode -> virtual key code maps. Our exported maps are
then included with rdesktop. You don't have about buggy XKB API, we're not
using it at all, and I don't plan on depending on it.

The idea is to export part of the XKB configuration database to keycode
->virtual key code maps that we then include with rdesktop. I wrote the
exporting script in perl, and I wrote parsing functions in rdesktop that
loads the map. We do not depend on XKB API for anything in this process. I
made it so that we can use it in non-XKB environments.

On Fri, May 15, 2009 at 3:34 PM, Peter Åstrand <astrand@...> wrote:

> On Fri, 15 May 2009, Marc-André Moreau wrote:
>
>  1) Re-using the numbers you have said, we currently have about 40 keymaps
>> on a total of 120 possible keymaps that would constitute a complete set of
>> keymaps. 40 is still one third of 120, so we're not even halfway done in
>> order to bring full support for every keyboard layout.
>>
>
> True if you are just looking at the number or languages, but if you instead
> look at which countries and users that are actually using rdesktop, I would
> say that, in practice, we are covering almost all users and territories. We
> don't hear complains about missing keymaps from 2/3 of our users, right?
>
>
>  I understand that if we go on a case by case basis, adding keymaps for
>> whatever keyboard layout someone needs, it does not require much effort. The
>> problem is that not everybody using an unsupported keyboard layout would
>> bother submitting a bug report, or getting to know rdesktop better in order
>> to write a new keymap and then submit it. Less common keyboard layouts are
>> most likely to remain unsupported. Also, even if the majority of the keymaps
>> currently work well, it may happen that someone finds a bug in it and again
>> it is no big deal to fix it. However, this work of adding keymaps and
>> maintaining them on an on-demand basis as people find that their keyboard
>> layout is unsupported or broken could be solved using a "one for all"
>> solution. That's why I thought of XKB, because they already take care of
>> doing that job.
>>
>
> I agree, in principle it's better if we can avoid having "our own" keymaps.
> I'm just concerned that this will in practice be very complicated. But I
> would be happy if you could prove that I'm wrong.
>
>
>  You have mentioned that XKB has a lot of bugs. I have taken a look at the
>> bug reports for xkb:
>>
>> https://bugs.freedesktop.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=xke
>> yboard-config&content=
>>
>> And most of the bugs submitted are minor or cover aspects of the data base
>> that we wouldn't even be using (such as
>> the symbolic key name to keysym translation). Also, if we bother doing the
>> maintenance work for our own set of
>> keymaps, it would take just as much efforts to submit a bug report to XKB
>> instead, and fix it on our side. We would
>> benefit from that, and XKB would benefit from us (if we find bugs in their
>> database).
>>
>
> Yes, squashing bugs in the upstream XKB database is better than fixing our
> own keymaps, I agree, if we are just talking about the XKB data base.
>
> However, if we are talking about using the runtime XKEYBOARD extension as
> well, like Ilya Konstantinov suggests, we might suffer from many other bugs.
>
> Believe it or not, but the X.Org keyboard handling and input system is not
> at all stable, it's in more flux than ever. Eventually it might be very nice
> with MPX and everything, but the fact is that today, there are numerous
> problems both with XKB as well as the classical events.
>
>
>  Before going further, I need to explain more in depth the major
>> differences between my method and the current one:
>>
>
> Wow, that was a lot of text...
>
>
>  So, to summarize:
>>
> ...
>
>> Even if I'm using XKB as a basis to export new keymaps using my perl
>> script, we really aren't doing anything related
>> to XKBlib or using any functions from it. The keycode -> virtual keycode
>> -> scan code mapping is all done using my
>> code. We're not doing anything complex here. The only bugs that could
>> affect us related to XKB would be a bug in the
>> keycode -> symbolic key code maps. My mapping of symbolic key codes to
>> virtual key codes in my perl script is as
>> complete as I could make it. If a bug is found in my perl script, it is
>> trivial to fix and re-export the database.
>>
>
> A quick summarize from my point of view: I'm positive to try to use the
> information in the XKB database. The idea of generating keymaps from it
> using a perl script or similar is nice. This way, however, we should in
> principle be able to keep the current keyboard implementation as-is. We
> could add minor enhancements say trying to detect the keyboard layout using
> XKB if available and things like that, but this would be small, independent
> enhancements that will work with the existing keymap format and existing
> keymaps.
>
> Is there any reason why this approach cannot be used?
>
> Patches must be small and reasonable atomic if I should be able to accept
> them with good confidence. I've downloaded your modified version and
> unpacked it over an existing rdesktop working copy, and the result is a
> "diff" which is 2693 lines long, and I haven't even included the "xkb"
> subdirectory. This is a lot. Small is beautiful.
>
>
>
> Regards, ---
> Peter Åstrand           ThinLinc Chief Developer
> Cendio AB               http://www.cendio.com
> Wallenbergs gata 4
> 583 30 Linköping        Phone: +46-13-21 46 00
>

On Fri, May 15, 2009 at 10:18 PM, Peter Åstrand <astrand@...> wrote:

> I'm referring to the g_keylayout variable in rdesktop, which defaults to
> 0x409, and is otherwise set by using the "map" keyword in keymap files. It
> is also sent in sec_out_mcs_data, under the section:
>
>        /* Client information */
>        out_uint16_le(s, SEC_TAG_CLI_INFO);


Yes, we're talking about the same thing.
This value tells the RDP server which Windows keyboard to install
temporarily for the session.

(Why secondary? I think that if the keyboard LCID is different from the
system's main one, it is installed IN ADDITION to the existing one, thus
"secondary".)


> This information tells the RDP server which keymap to use, ie how to
> interpret RDP scancodes.


Just to make it clear, the Windows Terminal Service doesn't use this value
to interpret anything. It installs a keyboard layout for the system (just
like you could do manually later, through the Control Panel) and then feeds
the received scancodes (letting Windows do the translation to WM_CHARs).


>  When the XKB extension is not available, we should fall back to the
>> existing facility (the one which uses rdesktop keymap files).
>>
>
> In other words: Lots of pain, no gain. If we can't get rid of the current
> implementation nor the keymaps, it's going to be a *lot* of work for
> basically no value.


I disagree. On XKB systems (most modern desktops), we won't use unreliable
pregenerated keymaps anymore = gain. Otherwise, we still have the old
fallback (at no additional devel cost to us) = no pain.

On Fri, May 15, 2009 at 10:34 PM, Peter Åstrand <astrand@...> wrote:

>  The idea of generating keymaps from it using a perl script or similar is
> nice.
>

I totally disagree. We're missing something important here.

XKB is two things. On one hand, the Xorg's XKB *database* is a pretty rich
database of worldwide keyboard layouts. On the other hand, it's an X11
extension with an API.

The database is not a standard. Assuming that any XKB layout that names
itself "us" gonna look the same is technically incorrect. That's why I'm
against pregenerating keymaps offline. We should look at what the user has
in runtime (through the XKB API), instead of assuming everyone who has "us"
or "ru" keyboard layout necessarily loaded it from the Xorg 7.0 database.

Also, XKB layouts can be tricky. It can be "us", it can be "us+ru" or
"us+ru+il(pc105)" or whatever. Again, we're trying to be too smart here,
instead of doing the RIGHT thing and asking the server, in runtime.

> You should find a perl script called xkb.pl in the xkb folder in my patch. To try it, all you have to do is download the latest version of the xkb
> configuration database here: http://xlibs.freedesktop.org/xkbdesc/xkeyboard-config-1.5.tar.bz2
> 
> Copy the perl script in the root of the directory of maps, and then run it. The script will generate new keycode -> virtual keycode maps in a "xkb" sub
> directory. You may also use the existing maps from your XKB installation if you have it installed.
> 
> The majority of new lines of source code is made of macro definitions and arrays of structures used for mapping. Most of the actual code that isn't made
> out of definitions is in xkbkeymap.c.
> 
> The reason why we can't make a perl script that will export keymaps in the current format from the XKB configuration database is because it is much more
> easier and efficient to map keycodes -> virtual key codes instead of doing key sym -> keycode -> virtual key code. key syms are already mapped according

If I understand you correctly, you are using the keycode at runtime? You 
can't do that; it doesn't have a meaning outside the installed keyboard 
layout mapping.

If not using XKB, applications are only "allowed" to use the keysyms.

Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

On Sat, 16 May 2009, Ilya Konstantinov wrote:

>       This information tells the RDP server which keymap to use, ie how to interpret RDP scancodes.
> 
> 
> Just to make it clear, the Windows Terminal Service doesn't use this value to interpret anything. It installs a keyboard layout for the system (just like
> you could do manually later, through the Control Panel) and then feeds the received scancodes (letting Windows do the translation to WM_CHARs).

>From a client perspective, we don't really care if it's Terminal Services 
or some other Windows subsystem that is responsible for the translation. 
All that is important is that the client must send a keymap so that the 
server know how to interpret the scanodes. Btw, RDP is not limited to 
Windows systems either; there are RDP servers for Linux as well (even 
though I think those are quite bizarre.)


> In other words: Lots of pain, no gain. If we can't get rid of the current implementation nor the keymaps, it's going to be a *lot* of work for
> basically no value.
>
> I disagree. On XKB systems (most modern desktops), we won't use 
> unreliable pregenerated keymaps anymore = gain. Otherwise, we still have 
> the old fallback (at no additional devel cost to us) = no pain.

You are surprising me. How can you say that there will be no additional 
development or cost to maintain two implementations?

Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

> On Fri, May 15, 2009 at 10:34 PM, Peter Åstrand <astrand@...> wrote:
>        The idea of generating keymaps from it using a perl script or similar is nice.
> 
> 
> I totally disagree. We're missing something important here.
> 
> XKB is two things. On one hand, the Xorg's XKB *database* is a pretty rich database of worldwide keyboard layouts. On the other hand, it's an X11
> extension with an API.

Yes, I know.


> The database is not a standard. Assuming that any XKB layout that names itself "us" gonna look the same is technically incorrect. That's why I'm against
> pregenerating keymaps offline. We should look at what the user has in runtime (through the XKB API), instead of assuming everyone who has "us" or "ru"
> keyboard layout necessarily loaded it from the Xorg 7.0 database.

Yes, if "pregenerating keymaps offline" means that we at runtime tries to 
interpret the keycodes, then I agree with you that this is wrong.


> Also, XKB layouts can be tricky. It can be "us", it can be "us+ru" or 
> "us+ru+il(pc105)" or whatever. Again, we're trying to be too smart here, 
> instead of doing the RIGHT thing and asking the server, in runtime.

Yes, using the XKB API to get the key names at runtime is in principle a 
sound design. The problem is just that I believe that relying on XKB and 
having two different implementations will be a pain.

What is the status of your XKB patch, is it up to date and complete?


Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

On Sat, May 16, 2009 at 9:58 AM, Peter Åstrand <astrand@...> wrote:

>
>> The database is not a standard. Assuming that any XKB layout that names
>> itself "us" gonna look the same is technically incorrect. That's why I'm
>> against
>> pregenerating keymaps offline. We should look at what the user has in
>> runtime (through the XKB API), instead of assuming everyone who has "us" or
>> "ru"
>> keyboard layout necessarily loaded it from the Xorg 7.0 database.
>>
>
> Yes, if "pregenerating keymaps offline" means that we at runtime tries to
> interpret the keycodes, then I agree with you that this is wrong.


That's what I'm saying all along. Marc's idea, if I understand him
correctly, is to leverage Xorg's XKB database as a rich database of keyboard
layouts. It's not really "using XKB" in the technical sense.


> Also, XKB layouts can be tricky. It can be "us", it can be "us+ru" or
>> "us+ru+il(pc105)" or whatever. Again, we're trying to be too smart here,
>> instead of doing the RIGHT thing and asking the server, in runtime.
>>
>
> Yes, using the XKB API to get the key names at runtime is in principle a
> sound design. The problem is just that I believe that relying on XKB and
> having two different implementations will be a pain.


I believe that since the vast majority of our X11 users are modern Xorg
installations, once we have an XKB-aware key mapper, it'll be the "main"
implementation.

We'll have two code paths, both receiving the same input (XKeyEvent) and
emitting the same output (AT scancode), so while more code is always a pain,
having both implementations doesn't make the code *around* them any more
complicated.


> What is the status of your XKB patch, is it up to date and complete?


See, that's where my proposal runs thin :) I've never implemented what I'm
talking about here, not in any complete form. I hate to be all-talk, and I
hate to put all this STOP ENERGY into Marc's work, seeing he's so eager to
help and contribute his time.

I haven't contributed much code to rdesktop the last year, since I moved to
a Mac (and, to be frank, I'm using Microsoft's own Mac client for my RDP
needs) but if you guys want me to, I'll whip up my Linux VM and put code
where my mouth is.

On Sat, May 16, 2009 at 9:49 AM, Peter Åstrand <astrand@...> wrote:

> On Sat, 16 May 2009, Ilya Konstantinov wrote:
>
>       This information tells the RDP server which keymap to use, ie how to
>> interpret RDP scancodes.
>>
>>
>> Just to make it clear, the Windows Terminal Service doesn't use this value
>> to interpret anything. It installs a keyboard layout for the system (just
>> like
>> you could do manually later, through the Control Panel) and then feeds the
>> received scancodes (letting Windows do the translation to WM_CHARs).
>>
>
> From a client perspective, we don't really care if it's Terminal Services
> or some other Windows subsystem that is responsible for the translation. All
> that is important is that the client must send a keymap so that the server
> know how to interpret the scanodes. Btw, RDP is not limited to Windows
> systems either; there are RDP servers for Linux as well (even though I think
> those are quite bizarre.)


>From a naive perspective, yes. But since you only send an LCID value (0x409
for English US etc.) and not really an accurate representation of your local
key-to-character mapping, you're at best making a honest effort to
approximate the local user preferences on the remote machine.

This belongs to the class of features which aim to keep remote preferences
similar to the local ones, to make the user feel at home on the remote
station. It's important, it's just *technically* a separate goal.

Goal #1: Send precise AT scancodes, no matter what. (As much as possible,
keep it language-agnostic, keep local language-specific keyboard mappings
out of the way.)
Goal #2: Give the remote server a good hint about the local keyboard
preferences.

Both goals important, and not dependent on each other.

Here a some precisions about my code:

1) It is currently in a working state. it may need some polishing work, but
the major part of the work is already done.
2) I am using the XKB *database* and nothing of the XKB *API*
3) Once the keycode->virtual key code map is loaded, I use keycodes at run
time and map them to virtual key codes, then to scan codes. ANY X program
receives the keycodes. Look in xwin.c. keycodes alone are unreliable as they
are hardware dependent, but that was the whole point of using the XKB
*database* to map them a consistent naming system (XKB key names / virtual
key codes). My perl script exports part of the XKB database to keycodes ->
virtual key codes, but reading keycodes -> XKB keynames maps and then
mapping XKB keynames to virtual key codes and writing that into a new file.

I still disagree that we should add XKB as a dependency. Ilya, how would you
get around the fact that XKB keynames are not exactly "ready" to be used?
How would you map them to scan codes? Mapping them their corresponding
virtual key code works perfectly, but I don't think it is a good idea to do
that at run time, there are tons of XKB keynames. You can take a look at the
perl script, the mapping from XKB keynames to virtual key code is done
there.

About your goal #1 and #2:

Goal #1: Send precise AT scancodes, no matter what. (As much as possible,
keep it language-agnostic, keep local language-specific keyboard mappings
out of the way.)
Goal #2: Give the remote server a good hint about the local keyboard
preferences.

My code mainly solves #1 with the usage of virtual key codes (language and
keyboard agnostic codes), but I have also worked a lot on #2. look like
locales.h for #2. xkbkeymap.c contains a function that finds the locale and
gets its corresponding locale ID, and then uses it to find a default
keyboard layout ID that would normally correspond to someone using that
locale. The hard coded maps between locale ID and keyboard layout ID are
made from documentation from Microsoft. I left the corresponding URLs in
comments.

On Sat, 16 May 2009, Ilya Konstantinov wrote:

> From a client perspective, we don't really care if it's Terminal Services or some other Windows subsystem that
> is responsible for the translation. All that is important is that the client must send a keymap so that the
> server know how to interpret the scanodes. Btw, RDP is not limited to Windows systems either; there are RDP
> servers for Linux as well (even though I think those are quite bizarre.) 
> 
> 
> From a naive perspective, yes. But since you only send an LCID value (0x409 for English US etc.) and not really an
> accurate representation of your local key-to-character mapping, you're at best making a honest effort to approximate
> the local user preferences on the remote machine.

Disagree. The local mappings are not relevant. I could have a totally 
obscure and "special" key mapping.


> This belongs to the class of features which aim to keep remote preferences similar to the local ones, to make the
> user feel at home on the remote station. It's important, it's just *technically* a separate goal.
> 
> Goal #1: Send precise AT scancodes, no matter what. (As much as possible, keep it language-agnostic, keep local
> language-specific keyboard mappings out of the way.)
> Goal #2: Give the remote server a good hint about the local keyboard preferences.

If we are not sending an appropriate layout code, those "precise AT 
scancodes" are meaningless and impossible for the RDP server to interpret.

Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

On Sat, 16 May 2009, Ilya Konstantinov wrote:

> That's what I'm saying all along. Marc's idea, if I understand him correctly, is to leverage Xorg's XKB database as
> a rich database of keyboard layouts. It's not really "using XKB" in the technical sense.

Still, if the database could be used to create more/better keymaps using 
the keysym-scancode approach (like the current keymaps), the XKB database 
could be very useful. This is the path I prefer.


> I believe that since the vast majority of our X11 users are modern Xorg installations, once we have an XKB-aware key
> mapper, it'll be the "main" implementation.

There are still a lot of systems where XKB is not available. For example, 
many thin terminals (which is a very common rdesktop platform) does not 
support XKB. Another example is Xvnc - we have tried but failed to get XKB 
working.


> We'll have two code paths, both receiving the same input (XKeyEvent) and emitting the same output (AT scancode), so
> while more code is always a pain, having both implementations doesn't make the code *around* them any more
> complicated.

But we would still having to maintain those keymaps etc. We already 
basically have two different paths in that the send-the-raw-keycode 
feature is still present. And when a user reports a keyboard problem, we 
wouldn't know which of our *three* code paths they are executing.


> See, that's where my proposal runs thin :) I've never implemented what I'm talking about here, not in any complete
> form. I hate to be all-talk, and I hate to put all this STOP ENERGY into Marc's work, seeing he's so eager to help
> and contribute his time.
> 
> I haven't contributed much code to rdesktop the last year, since I moved to a Mac (and, to be frank, I'm using
> Microsoft's own Mac client for my RDP needs) but if you guys want me to, I'll whip up my Linux VM and put code where
> my mouth is.

To be honest, if you are not using Linux and rdesktop any longer, I'm not 
sure this is a good idea. *If* we should go forward with XKB work, we'll 
need developers (preferrably more than one) that are willing to work on 
this over a long period of time, with bug fixes and things like that.


Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

On Sat, 16 May 2009, Marc-André Moreau wrote:

> 3) Once the keycode->virtual key code map is loaded, I use keycodes at run time and map them to virtual key codes,
> then to scan codes. ANY X program receives the keycodes. Look in xwin.c.

Sure, but that doesn't mean that they are usable.


> keycodes alone are unreliable as they are
> hardware dependent, but that was the whole point of using the XKB *database* to map them a consistent naming system
> (XKB key names / virtual key codes).

The problem is just that you are using one mapping at build time (the XKB 
database) but another at runtime (the current Xserver keyboard mapping). 
This means that you cannot trust that the keycodes are the same: They can 
differ in a number of cases: When the used version of the XKB database 
differs, when you are running another platform at runtime (say, Solaris), 
when you move between "normal" and "evdev" systems, if you use Xvnc etc 
etc.

For a normal application, looking at the "keycode" is simply a big no-no.

Using the "keysyms" is the preferred approach; works on all platforms.

Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

On Mon, May 18, 2009 at 2:34 AM, Peter Åstrand <astrand@...> wrote:

> On Sat, 16 May 2009, Marc-André Moreau wrote:
>
>  3) Once the keycode->virtual key code map is loaded, I use keycodes at run
>> time and map them to virtual key codes,
>> then to scan codes. ANY X program receives the keycodes. Look in xwin.c.
>>
>
> Sure, but that doesn't mean that they are usable.
>
>
>  keycodes alone are unreliable as they are
>> hardware dependent, but that was the whole point of using the XKB
>> *database* to map them a consistent naming system
>> (XKB key names / virtual key codes).
>>
>
> The problem is just that you are using one mapping at build time (the XKB
> database) but another at runtime (the current Xserver keyboard mapping).
> This means that you cannot trust that the keycodes are the same: They can
> differ in a number of cases: When the used version of the XKB database
> differs, when you are running another platform at runtime (say, Solaris),
> when you move between "normal" and "evdev" systems, if you use Xvnc etc etc.
>
> For a normal application, looking at the "keycode" is simply a big no-no.
>
> Using the "keysyms" is the preferred approach; works on all platforms.
>
>
No, no! You're missing the point again. Please understand that keysyms are
already translated according to the local keyboard layout and that we do NOT
want to deal with them. keycodes are codes that correspond to one key on the
keyboard, but the code may differ according to your keyboard. That is where
XKB keynames are used: keycodes are mapped to an XKB keyname that is
consistent for all keyboards. the XKB keynames are then used by XKB to
correctly map a keycode to a keysym. If you're thinking of using keysyms,
you're doing it wrong. What you need is the map from keycode (inconsistent)
to XKB keynames (consistent). My code already uses that, and does not depend
on XKB _at all_. The maps are included with rdesktop so that you do not rely
on XKB. It works on all platforms, and better than with keysyms.

To summarize:

keycodes: inconsistent numbers corresponding to a key on a keyboard

XKB keynames: _consistent_ naming of keys on a keyboard

keysym: resulting character that corresponds to a keystroke, and varies
according to the keyboard layout.


Sorry if I'm losing my patience a little bit, but I don't understand why you
keep arguing on this when all you have to do is take a look at my source
code and what I've done. I carefully thought of all of this. My solution
should satisfy both of you if you at least cared a little more about trying
it.

exporting keycode -> XKB keynames maps to keycode -> virtual key code maps
and then including that with rdesktop is definitely the most efficient way
to do it that won't depend on XKB at all.

It provides a consistent and reliable way to do it, independently of any XKB
installation. Remember, we're just using an exported version of the data,
and nothing from the XKB API. It works on systems that do not have XKB
installed. And it works better than using keysyms which are already
translated according to the keyboard layout.

Another simple argument against keysyms: for instance, you have an azerty
keyboard. It doesn't matter if you have an azerty keyboard, you will still
have to send the scan codes corresponding to Microsoft virtual key codes.
This means that to send 'A', you will have to send 'Q' and it will be
interpreted on the server end according to an azerty keyboard layout to
result with an 'A'. Now, try to make that kind of translation simple when
dealing with that kind of problems. keysyms are already translated according
to keyboard layout and we are trying to avoid that, we want the data _raw_.
To achieve that we take the scan code and we translate it to a consistent
virtual key code, and we send it's corresponding scan code, and that's it.
We don't deal with the keysyms or the current keyboard layout at all and we
certainly do not want that. keycodes are available on all systems just like
keysyms are. look at xwin.c again if you don't trust me.

By the way, microsoft solved the problem of inconsistent keycodes with
virtual key codes. on UNIX, they just made a different but equivalent system
with the XKB keynames. We're just mapping one system to the other, and it
works perfectly. Key 'Q' is still key 'Q', no matter if it is an azerty
keyboard with the letter 'A' written on it. This is only meaningful when the
key strokes are translated to resulting characters, not before that.

On Mon, 18 May 2009, Marc-André Moreau wrote:

> Sure, but that doesn't mean that they are usable.
> 
>
>       keycodes alone are unreliable as they are
>       hardware dependent, but that was the whole point of using the XKB *database* to map them a
>       consistent naming system
>       (XKB key names / virtual key codes).

Perhaps an example helps. In a typical Xvnc session, you have have a 
layout that includes this mapping:

$ xmodmap -pke | grep aring
keycode 255 = aring

To get a "aring" in the remove RDP session, one needs to send a keyboard 
layout code of 0x0000041d, and then the scancode 0x1a.

Now tell me: How do you know that the keycode 255 should be translated to 
scancode 0x1a, by using the XKB database?

Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

0x0000041d = Swedish keyboard layout

scan code 0x1a corresponds to virtual key code VK_OEM_4

Using a set of maps exported from the XKB database, a map of keycodes to
virtual key codes would be loaded. 0x0000041d would be sent either
automatically from auto-detection of keyboard layout or from user specified
settings, in order to specify a Swedish keyboard layout. When the user would
press the key that is _consistently_ called VK_OEM_4, rdesktop would send
scan code 0x1a, and the server would then interpret 0x1a as being aring
according to the Swedish keyboard layout.


Look in keyboard.h, you should find a map of keyboard layout IDs to their
names:

keyboardLayout keyboardLayouts[] =
{
    { 0x00000401, "Arabic (101)" },
    { 0x00000402, "Bulgarian" },
    { 0x00000404, "Chinese (Traditional) - US Keyboard" },
    { 0x00000405, "Czech" },
    { 0x00000406, "Danish" },
    { 0x00000407, "German" },
    { 0x00000408, "Greek" },

....

    { 0x00001009, "Canadian French" },
    { 0x0000100C, "Swiss French" },
    { 0x0000141A, "Bosnian" },
    { 0x00001809, "Irish" },
    { 0x0000201A, "Bosnian Cyrillic" }
};


Take a closer look at the map from virtual key code to scan code:

virtualKey virtualKeyboard[256] =
{
    { 0x00, "" },
    { 0x00, "VK_LBUTTON" },
    { 0x00, "VK_RBUTTON" },
    { 0x00, "VK_CANCEL" },
    { 0x00, "VK_MBUTTON" },
    { 0x00, "VK_XBUTTON1" },
    { 0x00, "VK_XBUTTON2" },

...

    { 0x1A, "VK_OEM_4" },
    { 0x2B, "VK_OEM_5" },
    { 0x1B, "VK_OEM_6" },
    { 0x28, "VK_OEM_7" },
    { 0x1D, "VK_OEM_8" },

...

(I'm truncating the maps because they are quite big, look at the source code
for the complete one)


Look in xkb.pl, the big hash table that maps XKB keynames to virtual key
codes:

my %sym2virt = (
    "AE00" => "VK_TILDE",
    "AE01" => "VK_KEY_1",
        "AE02" => "VK_KEY_2",
        "AE03" => "VK_KEY_3",
        "AE04" => "VK_KEY_4",
        "AE05" => "VK_KEY_5",
        "AE06" => "VK_KEY_6",

...

        "AD06" => "VK_KEY_Y",
        "AD07" => "VK_KEY_U",
        "AD08" => "VK_KEY_I",
        "AD09" => "VK_KEY_O",
        "AD10" => "VK_KEY_P",
        "AD11" => "VK_OEM_4",
        "AD12" => "VK_OEM_6",

...


Now, download xkeyboard-config 1.5 and take a look at what the XKB database
looks like in its original form:

xkb_keycodes "pc_common" {
    // "Function" keys
    <FK01>    = 9;
    <FK02>    = 15;
    <FK03>    = 23;
    <FK04>    = 31;
    <FK05>    = 39;

...

    // "Alphanumeric" keys
    <AE01>    = 22;
    <AE02>    = 30;
    <AE03>    = 38;
    <AE04>    = 37;
    <AE05>    = 46;
    <AE06>    = 54;
    <AE07>    = 61;
    <AE08>    = 62;

...


And now, take a look at what it looks like in the keycode->virtual key code
format as exported by my perl script:

keyboard "pc_common"
{
    VK_F1        <9>
    VK_F2        <15>
    VK_F3        <23>
    VK_F4        <31>
    VK_F5        <39>
    VK_F6        <47>
    VK_F7        <55>
    VK_F8        <63>
    VK_F9        <71>

...

    VK_OEM_4    <84>
    VK_OEM_6    <91>
    VK_CAPITAL    <20>
    VK_KEY_A    <28>
    VK_KEY_S    <27>
    VK_KEY_D    <35>
    VK_KEY_F    <43>
    VK_KEY_G    <52>

...

Now, take a look at xkbkeymap.c for the function loadKeyboard(char* kbd)

The function will load a keycode->virtual keycode map from the exported
maps. When loaded, the name of the virtual key code is taken, and then its
corresponding virtual key code (the number) is found by looking in the array
shown earlier (virtualKey virtualKeyboard[256]...). The map that is used at
run time is an array of 256 unsigned chars. The index in the array
corresponds to the keycode, and the value at the index is the resulting
virtual key code. When the user presses a key, my code will simply look for
the value at the index corresponding to the keycode of the last keystroke,
and will use that value as an index in virtualKey virtualKeyboard[256] to
get the corresponding scan code instantly.

On Mon, May 18, 2009 at 3:29 AM, Peter Åstrand <astrand@...> wrote:

> On Mon, 18 May 2009, Marc-André Moreau wrote:
>
>  Sure, but that doesn't mean that they are usable.
>>
>>
>>      keycodes alone are unreliable as they are
>>      hardware dependent, but that was the whole point of using the XKB
>> *database* to map them a
>>      consistent naming system
>>      (XKB key names / virtual key codes).
>>
>
> Perhaps an example helps. In a typical Xvnc session, you have have a layout
> that includes this mapping:
>
> $ xmodmap -pke | grep aring
> keycode 255 = aring
>
> To get a "aring" in the remove RDP session, one needs to send a keyboard
> layout code of 0x0000041d, and then the scancode 0x1a.
>
> Now tell me: How do you know that the keycode 255 should be translated to
> scancode 0x1a, by using the XKB database?
>
>
> Rgds, ---
> Peter Åstrand           ThinLinc Chief Developer
> Cendio AB               http://www.cendio.com
> Wallenbergs gata 4
> 583 30 Linköping        Phone: +46-13-21 46 00
>

> 0x0000041d = Swedish keyboard layout
> 
> scan code 0x1a corresponds to virtual key code VK_OEM_4
> 
> Using a set of maps exported from the XKB database, a map of keycodes to virtual key codes would be loaded.
> 0x0000041d would be sent either automatically from auto-detection of keyboard layout or from user specified
> settings, in order to specify a Swedish keyboard layout. When the user would press the key that is _consistently_
> called VK_OEM_4, rdesktop would send scan code 0x1a, and the server would then interpret 0x1a as being aring
> according to the Swedish keyboard layout.

But how would rdesktop know that it should translate keycode 255 to 
VK_OEM_4? The answer is that it cannot, since there's no keycode with 
value 255 at all in the XKB database. Besides, the keycode might be 255 
today, but 254 or something else tomorrow. Please try to understand that 
your approach of looking at the keycode does not work.


Rgds, 
---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

keycode 255 is a special case. I found this:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6678061
We could just directly map keycode 255 to VK_OEM_4. Normally this keycode
isn't used.

How does it know that VK_OEM_4 has been pressed, if keycodes can't be used
as you say? Because XKB maintains a database of keycodes -> XKB keynames.
How many times do I have to repeat it? Yes, the keycode DOES change, it
isn't a constant, it will vary from one keyboard to another. THAT IS THE
WHOLE POINT OF USING XKB.

for instance, if I'm using digital_vndr/pc(pc_common) map from XKB, I get:

    VK_OEM_4    <84>

And now, if I look at digital_vndr/lk(lk_common):

    VK_OEM_4    <250>

And now, if I look at sun(type4):

    VK_OEM_4    <71>

Oh my God! What am I seeing? Different keycodes mapping to the same name?
Wasn't that the whole point of using XKB? Mapping different keycodes that
refer to the same key to a consistent naming system? Yes it is!

What the fuck is wrong with you guys? I'm here, submitting a damn patch
that's actually good, and you guys can't even manage to read it carefully
enough to understand what it is doing really. Instead, you insist on making
me repeat the same things over and over again, and when I think you finally
get it, no! You totally miss the point again. Keep your broken input system
if that is your wish, I'm so pissed at how bad this can be that I'm very
tempted to fork the damn project.

On Wed, May 20, 2009 at 6:39 AM, Peter Åstrand <astrand@...> wrote:

>
>  0x0000041d = Swedish keyboard layout
>>
>> scan code 0x1a corresponds to virtual key code VK_OEM_4
>>
>> Using a set of maps exported from the XKB database, a map of keycodes to
>> virtual key codes would be loaded.
>> 0x0000041d would be sent either automatically from auto-detection of
>> keyboard layout or from user specified
>> settings, in order to specify a Swedish keyboard layout. When the user
>> would press the key that is _consistently_
>> called VK_OEM_4, rdesktop would send scan code 0x1a, and the server would
>> then interpret 0x1a as being aring
>> according to the Swedish keyboard layout.
>>
>
> But how would rdesktop know that it should translate keycode 255 to
> VK_OEM_4? The answer is that it cannot, since there's no keycode with value
> 255 at all in the XKB database. Besides, the keycode might be 255 today, but
> 254 or something else tomorrow. Please try to understand that your approach
> of looking at the keycode does not work.
>
>
>
> Rgds, ---
> Peter Åstrand           ThinLinc Chief Developer
> Cendio AB               http://www.cendio.com
> Wallenbergs gata 4
> 583 30 Linköping        Phone: +46-13-21 46 00
>

> keycode 255 is a special case. I found this:
> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6678061
> We could just directly map keycode 255 to VK_OEM_4. Normally this keycode isn't used.

Regardless of what you map it to at build time, it can be incorrect at 
runtime, since the keycode can vary from day to day. Xvnc allocates 
keycodes the first time you press a certain key/symbol.


> How does it know that VK_OEM_4 has been pressed, if keycodes can't be used as you say? Because XKB maintains a database of keycodes -> XKB keynames. How
> many times do I have to repeat it? Yes, the keycode DOES change, it isn't a constant, it will vary from one keyboard to another. THAT IS THE WHOLE POINT

The problem is that it's not even stable for the same keyboard.


>What the fuck is wrong with you guys? I'm here, submitting a damn patch 
>that's actually good, and you guys can't even manage to read it carefully 
>enough to understand what it is doing really. Instead, you insist on 
>making me repeat the same things over and over again, and when I think 
>you finally get it, no! You totally miss the point again. Keep your 
>broken input system if that is your wish, I'm so pissed at how bad this 
>can be that I'm very tempted to fork the damn project.

If you are still convinced that your implementation is good, why don't you 
try it within a Xvnc session, for example, with the "aring" symbol that I 
used in my example?


---
Peter Åstrand		ThinLinc Chief Developer
Cendio AB		http://www.cendio.com
Wallenbergs gata 4
583 30 Linköping	Phone: +46-13-21 46 00

Ok, here is a screenshot:

http://img140.imageshack.us/img140/691/aringvnc.png

In the screenshot, you should see that I am accessing my Ubuntu laptop from
my Debian desktop computer (using VNC), and from the Ubuntu laptop I am
using my patched version of rdesktop to remotely access a third computer
running Windows. I changed the keyboard layout to a Swedish keyboard layout,
and pressed VK_OEM_4 on my Debian computer, and see the result... "aring"!

On Wed, May 20, 2009 at 2:49 PM, Peter Åstrand <astrand@...> wrote:

>
>  keycode 255 is a special case. I found this:
>> http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6678061
>> We could just directly map keycode 255 to VK_OEM_4. Normally this keycode
>> isn't used.
>>
>
> Regardless of what you map it to at build time, it can be incorrect at
> runtime, since the keycode can vary from day to day. Xvnc allocates keycodes
> the first time you press a certain key/symbol.
>
>
>  How does it know that VK_OEM_4 has been pressed, if keycodes can't be used
>> as you say? Because XKB maintains a database of keycodes -> XKB keynames.
>> How
>> many times do I have to repeat it? Yes, the keycode DOES change, it isn't
>> a constant, it will vary from one keyboard to another. THAT IS THE WHOLE
>> POINT
>>
>
> The problem is that it's not even stable for the same keyboard.
>
>
>  What the fuck is wrong with you guys? I'm here, submitting a damn patch
>> that's actually good, and you guys can't even manage to read it carefully
>> enough to understand what it is doing really. Instead, you insist on making
>> me repeat the same things over and over again, and when I think you finally
>> get it, no! You totally miss the point again. Keep your broken input system
>> if that is your wish, I'm so pissed at how bad this can be that I'm very
>> tempted to fork the damn project.
>>
>
> If you are still convinced that your implementation is good, why don't you
> try it within a Xvnc session, for example, with the "aring" symbol that I
> used in my example?
>
>
>
> ---
> Peter Åstrand           ThinLinc Chief Developer
> Cendio AB               http://www.cendio.com
> Wallenbergs gata 4
> 583 30 Linköping        Phone: +46-13-21 46 00
>