From: Marc-André M. <mar...@gm...> - 2009-04-15 06:25:38
|
Hi, It has been a while since the discussion about rdesktop using XKB. I've worked on it from time to time, and I finally got something which is usable :) Download it here: http://www.awakecoding.com/downloads/rdesktop_mod.zip Unzip the contents of the archive over the latest sources, and then add xkbkeymap.o to the following line in the Makefile: X11OBJ = rdesktop.o xwin.o xkbkeymap.o xkeymap.o ewmhints.o xclip.o cliprdr.o And it should compile. For the moment, I expect it to work fine at least under any system with XKB, but the magic of the thing is that it doesn't depend on any pre-existing XKB installation. The reason for this patch is that rdesktop currently has its down separate keymap database that it keeps updating and fixing. The way the keymaps currently works is that it maps keysyms (almost the resulting characters you'd see on your screen corresponding to a keystroke) to scan codes used by the remote desktop protocol. As there are tons of different keyboard layouts, it means tons of possible keymaps we'd have to make so that we correctly map everything for each keyboard layout. It also means that if on the client side we change the keyboard layout while rdesktop is running, the keymap will now be wrong (still mapping for the previous keyboard layout), unless you restart rdesktop. I've been thinking about the problem and about a "cleaner" way to solve it. I thought of the XKB configuration database, which is separate from XKB itself and intends to be an up to date and accurate keymap database usable for everyone. Could we ask for a better thing? They're already supporting way much more keyboards than we do, so I thought it would only be for the better. Now, what part of XKB is the best to use. Considering that we're sending scan codes through the remote desktop protocol, it makes sense to simply map keycodes -> virtual key codes -> scan codes. Why not keycodes to scan codes directly? Because they're not always the same for the same key, and that is pretty much why Microsoft made virtual key codes for. So, keycodes -> virtual key codes -> scan codes is the most efficient and accurate. It doesn't even depend on the current keyboard layout, all we have to know is the keyboard type (the default type just works fine with pretty much every "common" keyboard, a significantly different one would be a japanese keyboard). For systems with XKB, what I'm doing in the patch at the moment is that I call setxkbmap -print and get the current XKB keyboard type out of that. This requires no linkage with XKBlib, which is nice. I said at the beginning that it doesn't require any pre-existing XKB installation. The reason is that I've made a perl script which exports only the part of the XKB configuration database that is needed, making a new one out of it that maps only keycodes to virtual key codes. Maintaining rdesktop's XKB configuration database is as simple as running the perl script on newer versions of the XKB configuration database that contain fixes. The mapping from virtual key codes to scan codes is made using an array of structures containing the mapping, so that for instance: virtualKeyboard[VK_SPACE].scancode gives you the scan code for VK_SPACE. The new XKB configuration database that is exported by the perl script can be located anywhere where the current keymap folder is. I've made rdesktop search for the folder in the same places. There is more. I've made a lot of work on finding the current possible keyboard layout from the current locale. What I found is that in the current rdesktop code, the locale of the system would be used to find a keymap of the same name as the locale. The keymap would then contain the keyboard layout code that is sent to the remote desktop server. I used the locale IDs and default keyboard layouts from Microsoft, and made a table out of it. I also make complete tables of all the keyboard layouts and the ID that should be sent to announce to the remote desktop server what keyboard layout to use. this is all in keyboard.h Now, an overview of the files contained in the patch: Keyboard.h: Macro definitions for all virtual key codes Default built-in keymap Virtual key code to scan code conversion map Keyboard layout IDs + Name in an array of structures. Same for keyboard layout variants and IMEs. Locales.h: Macro definitions for all locales (with locale ID) Locale country code + language code to locale ID map Default keyboard layouts for each locale, in an array of structures xkbkeymap.c: Functions to detect, initialize and load the keyboard layout Functions equivalent to what you have in xkeymap.c, but for XKB XKB Folder containing all the keycode -> virtual key code maps. XKB/xkb.pl Perl script to export the XKB configuration database to an easier to use format for rdesktop. What I plan to work on, next: Keyboard layout detection on non-XKB systems. I own a SPARC system running Solaris 10, and it doesn't have XKB. That would be my first target. OpenSolaris comes with X.org and XKB, so it should be fine for that one. I also have an old PowerPC mac that runs Mac OS X Tiger, I would eventually take the time to write keyboard layout detection function that reads it from the current Mac OS X configuration. I would like to know your comments and advice for the work that would still need to be done on this. If anybody is using a japanese keyboard I would require his assistance in order to ensure that it works fine with those keyboards. Weird sun keyboards should be working fine if XKB is correctly set for that keyboard. In other words, whatever is supported by XKB should be supported by rdesktop with that. |
From: Peter Å. <as...@ce...> - 2009-05-14 12:50:50
|
> It has been a while since the discussion about rdesktop using XKB. I've worked on it from time to time, > and I finally got something which is usable :) Download it here: Hi. Having written the current keyboard implementation in rdesktop, I believe I should comment on this. > The reason for this patch is that rdesktop currently has its down separate keymap database that it keeps > updating and fixing. The way the keymaps currently works is that it maps keysyms (almost the resulting > characters you'd see on your screen corresponding to a keystroke) to scan codes used by the remote desktop > protocol. As there are tons of different keyboard layouts, it means tons of possible keymaps we'd have to > make so that we correctly map everything for each keyboard layout. I disagree. There are actually only 120 or so keymaps in total, and many of these are variations with little changes. We currently have ~ 40 keymaps, and most of them works very well. The effort required to add a new keymap if small - much smaller than a large source code change like added XKB support. > It also means that if on the client side we change the keyboard layout > while rdesktop is running, the keymap will now be wrong (still mapping > for the previous keyboard layout), unless you restart rdesktop. It doesn't matter if you change the keyboard layout on the rdesktop side - the keysyms will still be relevant. In fact, it's important to support cases when the local keymap differs from the remote one. What's important is the ability to change the remote, and therefore the over-the-wire, keymap. It is correct that the current implementation does not support this, but I don't see any fundamental problem with adding support for this. Of course, we also need to figure out if/how you can change the RDP keymap, but that's a separate issue. In any case, I don't think this has anything to do with XKB. > I've been thinking about the problem and about a "cleaner" way to solve > it. I thought of the XKB configuration database, which is separate from > XKB itself and intends to be an up to date and accurate keymap database > usable for everyone. Could we ask for a better thing? They're already > supporting way much more keyboards than we do, so I thought it would > only be for the better. I think it's useful to separate the translation data from the implementation, and it's a good thing that this has been done with the XKB config database. However, this also means that it is not necessary to change rdesktop to use XKB at runtime just to benefit from the XKB databases. It should be possible to generate the rdesktop keymaps, in its current format, from the XKB databases. In fact, this is how the initial keymaps were created (although this conversion was far from perfect). > Now, what part of XKB is the best to use. Considering that we're sending > scan codes through the remote desktop protocol, it makes sense to simply > map keycodes -> virtual key codes -> scan codes. Why not keycodes to > scan codes directly? Because they're not always the same for the same > key, and that is pretty much why Microsoft made virtual key codes for. > So, keycodes -> virtual key codes -> scan codes is the most efficient > and accurate. It doesn't even depend on the current keyboard layout, all > we have to know is the keyboard type (the default type just works fine > with pretty much every "common" keyboard, a significantly different one > would be a japanese keyboard). For systems with XKB, what I'm doing in > the patch at the moment is that I call setxkbmap -print and get the > current XKB keyboard type out of that. This requires no linkage with > XKBlib, which is nice. Are you referring to libxkbfile.so? Yes, it's good to get rid of that dependency, but introducing the new dependency of having to execute setxkbmap at runtime is not good. Many embedded systems does not have such binaries (or XKB support at all). > There is more. I've made a lot of work on finding the current possible keyboard layout from the current > locale. What I found is that in the current rdesktop code, the locale of the system would be used to find > a keymap of the same name as the locale. The keymap would then contain the keyboard layout code that is Looking at the locale is not very reliable. It's very common that the locale and the keymap differs. rdesktop uses it just because it's better than default to "en-us", but we can't rely on the locale. > I would like to know your comments and advice for the work that would still need to be done on this. If > anybody is using a japanese keyboard I would require his assistance in order to ensure that it works fine > with those keyboards. Weird sun keyboards should be working fine if XKB is correctly set for that > keyboard. In other words, whatever is supported by XKB should be supported by rdesktop with that. As before, I'm not convinced that throwing out the current implementation and replacing it with another XKB-based one is worth it. Keyboard handling is very complex and XKB is even more so. There are tons of bugs in this area (even in modern X.Org servers). If we should do this, there must be real benefits, and so far I haven't understood which those are. That said, feel free to continue working on this. I'm grateful for every contribution. Best 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 |
From: Marc-André M. <mar...@gm...> - 2009-05-15 04:37:07
|
Hi Peter, Thanks for taking the time to answer to my email, I appreciate it. I have answers to bring : 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. 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. 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=xkeyboard-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). Before going further, I need to explain more in depth the major differences between my method and the current one: 1) I am exporting a data base of keycodes -> virtual key codes for different keyboard _types_ and not keyboard layouts. This means that all bugs related to keyboard layouts in XKB would not affect us. The part of XKB which I am using to export a new data base in an easier to use format are the keymaps for keycodes -> symbolic key codes. In other words, the perl script that I wrote to export the XKB data base to another format will produce keymaps so that for instance on all keyboard types we will be able to get VK_ESCAPE when the escape key is pressed, no matter if the keycode differs. The remote desktop protocol uses scan codes that correspond to virtual key codes. 2) I've taken a look at the current source code, and the current keyboard layout detection is based on the system's locale. It gets the locale, and then looks in the keymaps folder to find a file of the same name as the locale. The file then contains the keyboard layout ID and the keymap itself. You have mentioned that relying on the locale to detect the keyboard layout was unreliable and I totally agree with you. It is, however, something that should be provided if no other means of detecting the current layout is available. In my code, I have made a complete map of locale names to locale IDs, and then locale IDs to the keyboard layout ID that someone using that locale would most likely be using. This has an advantage over the current code: even if we don't have a more reliable way of detecting the current keyboard layout, we can at least make a better guess based on the locale. In the current code, if the locale does not correspond to a keymap, it would default to us-en. In my case, I am using canadian multilingual standard, an unsupported keymap. This comes out very ugly on the other side, as when I type an "é" (accented e) it will translate that as an e followed by a backslash. If I specific the fr-ca keyboard layout, the closest one to mine, I will get the "é" correctly but then if I type a "ç" (c with a cedilla) it will appear as a çc (c with a cedilla with an extra c). Unfortunately, keyboard layout variant IDs do not seem to be recognized when sent (canadian multilingual is one of the keyboard layout variants). I haven't fixed the problem with keyboard layout variants yet, but I can at least have something good with my code because I am not depending on the keyboard layout of the client, but simply on the keyboard type of the client. If keyboard type detection fails, it simply defaults to a generic keyboard mapping that works for most ordinary keyboards. People with weird keyboards (such as sun keyboards) could specify a keyboard type if detection fails, so that it works fine. Detection failure when looking for a keyboard type is much less a problem than failing to detect a keyboard layout, and when the default keyboard layout is most likely to break non-English keyboard layouts, especially accented characters. Using my code and failing to detect the keyboard type, it would default to a generic keymap that works for most common keyboards, and then as I put English as my locale I would have a us-en keyboard layout on the server side, that would work correctly, even if my keyboard layout on the client side is unsupported. I could also specify that I want a fr-ca keyboard layout, which is different from the one on the client side, and it would also work. As we agree on the fact that the locale is unreliable for keyboard layout detection, I added support for detection using existing XKB configuration. I didn't want to add XKB as a dependency as we want to maintain support for systems that do not have XKB, so this is why I check for presence of setxkbmap instead. If setxkbmap is not present, then the keyboard type detection will rely on the current locale instead. I am planning on gathering that type of info using operating system specific data, because there is no way of doing it accurately for all operating systems. checking for existing XKB settings is just one of the system-specific check that, if successful, is very useful for an accurate keyboard type detection. So, to summarize: My code uses part of the XKB data base exported to a different and more convenient format (keycode -> virtual key code). virtual key code -> scan code conversion is done using a simple map that also contains the virtual key code name that can be used for debug purposes (you can know the corresponding virtual key codes as you type) My code does not rely on the current keyboard layout to map keys to scan codes. It brings a more complete way of trying to detect the current keyboard layout based on the locale, but that is meant to be used only if nothing else can be used (we both agree that it isn't reliable). I provide a way of checking for existing XKB configuration as if it is present, it can be used for an accurate keyboard type detection. Also, if keyboard type detection fails, the default settings are less likely to break keyboard input as opposed to defaulting to us-en for a client not using us-en. 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. For the following, testing would need to be done, and detection of keyboard type and layout would need to be implemented for various operating systems, using the operating system specific settings. And, most important, this is a "one for all" solution, as opposed to the current solution. I hope this clarifies why my code brings benefits to rdesktop. I have already done the major part of the work, the rest is just testing and fixing possible bugs (and I'm still here to do that work). Thanks again for taking the time to comment my email. Regards, - Marc-André Moreau On Thu, May 14, 2009 at 8:20 AM, Peter Åstrand <as...@ce...> wrote: > It has been a while since the discussion about rdesktop using XKB. I've >> worked on it from time to time, >> and I finally got something which is usable :) Download it here: >> > > Hi. Having written the current keyboard implementation in rdesktop, I > believe I should comment on this. > > > The reason for this patch is that rdesktop currently has its down separate >> keymap database that it keeps >> updating and fixing. The way the keymaps currently works is that it maps >> keysyms (almost the resulting >> characters you'd see on your screen corresponding to a keystroke) to scan >> codes used by the remote desktop >> protocol. As there are tons of different keyboard layouts, it means tons >> of possible keymaps we'd have to >> make so that we correctly map everything for each keyboard layout. >> > > I disagree. There are actually only 120 or so keymaps in total, and many of > these are variations with little changes. We currently have ~ 40 keymaps, > and most of them works very well. The effort required to add a new keymap if > small - much smaller than a large source code change like added XKB support. > > > It also means that if on the client side we change the keyboard layout >> while rdesktop is running, the keymap will now be wrong (still mapping for >> the previous keyboard layout), unless you restart rdesktop. >> > > It doesn't matter if you change the keyboard layout on the rdesktop side - > the keysyms will still be relevant. In fact, it's important to support cases > when the local keymap differs from the remote one. > > What's important is the ability to change the remote, and therefore the > over-the-wire, keymap. It is correct that the current implementation does > not support this, but I don't see any fundamental problem with adding > support for this. Of course, we also need to figure out if/how you can > change the RDP keymap, but that's a separate issue. In any case, I don't > think this has anything to do with XKB. > > > I've been thinking about the problem and about a "cleaner" way to solve >> it. I thought of the XKB configuration database, which is separate from XKB >> itself and intends to be an up to date and accurate keymap database usable >> for everyone. Could we ask for a better thing? They're already supporting >> way much more keyboards than we do, so I thought it would only be for the >> better. >> > > I think it's useful to separate the translation data from the > implementation, and it's a good thing that this has been done with the XKB > config database. However, this also means that it is not necessary to change > rdesktop to use XKB at runtime just to benefit from the XKB databases. It > should be possible to generate the rdesktop keymaps, in its current format, > from the XKB databases. In fact, this is how the initial keymaps were > created (although this conversion was far from perfect). > > > Now, what part of XKB is the best to use. Considering that we're sending >> scan codes through the remote desktop protocol, it makes sense to simply map >> keycodes -> virtual key codes -> scan codes. Why not keycodes to scan codes >> directly? Because they're not always the same for the same key, and that is >> pretty much why Microsoft made virtual key codes for. So, keycodes -> >> virtual key codes -> scan codes is the most efficient and accurate. It >> doesn't even depend on the current keyboard layout, all we have to know is >> the keyboard type (the default type just works fine with pretty much every >> "common" keyboard, a significantly different one would be a japanese >> keyboard). For systems with XKB, what I'm doing in the patch at the moment >> is that I call setxkbmap -print and get the current XKB keyboard type out of >> that. This requires no linkage with XKBlib, which is nice. >> > > Are you referring to libxkbfile.so? Yes, it's good to get rid of that > dependency, but introducing the new dependency of having to execute > setxkbmap at runtime is not good. Many embedded systems does not have such > binaries (or XKB support at all). > > > There is more. I've made a lot of work on finding the current possible >> keyboard layout from the current >> locale. What I found is that in the current rdesktop code, the locale of >> the system would be used to find >> a keymap of the same name as the locale. The keymap would then contain the >> keyboard layout code that is >> > > Looking at the locale is not very reliable. It's very common that the > locale and the keymap differs. rdesktop uses it just because it's better > than default to "en-us", but we can't rely on the locale. > > > I would like to know your comments and advice for the work that would >> still need to be done on this. If >> anybody is using a japanese keyboard I would require his assistance in >> order to ensure that it works fine >> with those keyboards. Weird sun keyboards should be working fine if XKB is >> correctly set for that >> keyboard. In other words, whatever is supported by XKB should be supported >> by rdesktop with that. >> > > As before, I'm not convinced that throwing out the current implementation > and replacing it with another XKB-based one is worth it. Keyboard handling > is very complex and XKB is even more so. There are tons of bugs in this area > (even in modern X.Org servers). If we should do this, there must be real > benefits, and so far I haven't understood which those are. That said, feel > free to continue working on this. I'm grateful for every contribution. > > > Best 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 |
From: Ilya K. <fu...@sh...> - 2009-05-15 08:05:31
|
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 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, there's no need to build rdesktop key mappings from XKB symbol maps, there's NO NEED TO DO ANYTHING LIKE THAT. I've already discussed it on the list in the past: http://article.gmane.org/gmane.network.rdesktop.devel/2757 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. Then, upon receiving an XKeyEvent: 1. Take the keycode (e.g. 67 -- may be different on your hardware) 2. Pass it through the keycode -> keyname table (e.g. keycode 67 -> <FK01>) we've generated in stages 1+2 3. Use the static hardware-independent language-independent mapping we've generated in stage 3 to map <FK01> -> whatever AT (RDP) scancode it maps to 4. Send this scancode in the RDP packet Presto! |
From: Peter Å. <as...@ce...> - 2009-05-15 14:34:51
|
> 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... > 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. > 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? 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 |
From: Ilya K. <fu...@sh...> - 2009-05-15 14:49:40
|
On Fri, May 15, 2009 at 5:34 PM, Peter Åstrand <as...@ce...> 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). |
From: Marc-André M. <mar...@gm...> - 2009-05-15 19:03:35
|
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 <fu...@sh...>wrote: > On Fri, May 15, 2009 at 5:34 PM, Peter Åstrand <as...@ce...> 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). > |
From: Mads K. <ma...@ki...> - 2009-05-15 14:56:06
|
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 |
From: Ilya K. <fu...@sh...> - 2009-05-15 15:32:35
|
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 <ma...@ki...> 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 > rde...@li... > https://lists.sourceforge.net/lists/listinfo/rdesktop-devel > |
From: Peter Å. <as...@ce...> - 2009-05-15 19:18:31
|
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 |
From: Peter Å. <as...@ce...> - 2009-05-15 19:35:06
|
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 |
From: Marc-André M. <mar...@gm...> - 2009-05-15 20:10:57
|
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 <as...@ce...> 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 > |
From: Peter Å. <as...@ce...> - 2009-05-16 06:42:27
|
> 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 |
From: Ilya K. <fu...@sh...> - 2009-05-15 23:55:42
|
On Fri, May 15, 2009 at 10:18 PM, Peter Åstrand <as...@ce...> 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. |
From: Ilya K. <fu...@sh...> - 2009-05-16 00:02:53
|
On Fri, May 15, 2009 at 10:34 PM, Peter Åstrand <as...@ce...> 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. |
From: Peter Å. <as...@ce...> - 2009-05-16 06:49:44
|
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 |
From: Peter Å. <as...@ce...> - 2009-05-16 06:59:10
|
> On Fri, May 15, 2009 at 10:34 PM, Peter Åstrand <as...@ce...> 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 |
From: Ilya K. <fu...@sh...> - 2009-05-16 11:43:27
|
On Sat, May 16, 2009 at 9:58 AM, Peter Åstrand <as...@ce...> 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. |
From: Peter Å. <as...@ce...> - 2009-05-18 06:25:06
|
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 |
From: Ilya K. <fu...@sh...> - 2009-05-16 11:52:02
|
On Sat, May 16, 2009 at 9:49 AM, Peter Åstrand <as...@ce...> 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. |
From: Peter Å. <as...@ce...> - 2009-05-18 06:10:44
|
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 |
From: Marc-André M. <mar...@gm...> - 2009-05-16 12:23:45
|
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. |
From: Peter Å. <as...@ce...> - 2009-05-18 06:34:29
|
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 |
From: Marc-André M. <mar...@gm...> - 2009-05-18 07:10:54
|
On Mon, May 18, 2009 at 2:34 AM, Peter Åstrand <as...@ce...> 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. |
From: Peter Å. <as...@ce...> - 2009-05-18 07:29:12
|
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 |