I'm using Xlib for a project, and I'm trying to get the KeySym relative to a pressed key.
I've got the KeyCode relative to the pressed key, keyboard modifiers and keyboard indicators. I'm referring to this page to understand how to retrieve the correct key, but it must be out of date or something, because my X doesn't behave like that page says.
I've got some questions:
What is MODE SWITCH? How can I see what key is my MODE SWITCH and how can I set it? (via Xlib functions or via a command, it's the same).
That page says that the first 4 KeySyms associated to a KeyCode (found with XGetKeyboardMapping, or shown by xmodmap -pk command) are divided into two groups. MODE SWITCH switches between groups, and within a group the first or the second KeySym is chosen according to modifiers (ie, shift key) or indicators (ie, caps lock). But on my X I can see that if shift is pressed, I switch to the third KeySym, not the second one.
On many european layouts AltGr key is bound to KeySym XS_ISO_Level3_Shift, which doesn't belong to any keyboard modifier (ie, shift, lock, control, mod1, mod2, mod3, mod4 and mod5). When such XS_ISO_Level3_Shift is pressed, the fifth KeySym associated to the KeyCode is chosen. Why? Where can I found some info about this XS_ISO_Level3_Shift and about other keysyms that are actually used, but not documented on Xlib manuals?
It looks like the page you're reading predates Xkb - I'd guess that content is 10-15 years old at least.
See: http://www.xfree86.org/current/XKBproto.pdf
"xmodmap -pm" will show you the modifier keys such as mode switch.
With Xkb, the behavior of basically everything is configurable, I believe. Start looking at /usr/share/X11/xkb/ for example. I don't know a lot about it but hopefully looking at Xkb instead of old docs will get you pointed in the right direction.
Tronche's manual is incomplete. I found more info about keyboard functions in:
1. xlib.pdf
2. xlib html manual at static.cray-cyber.org. This doc is hidden and a bit broken. Links are typed in lowercase, but the actual documents are in uppercase. After correcting the urls in browser it's readable.
PDF is complete I guess. I don't know if [2] is complete too, but for example the chapter 16.2 (sorry, I can't give a link cause my link limit is exceeded) is far longer than in Tronche's doc.
I'm a beginner in understanding xlib, that's what I managed to google out today.
Related
For an automated test application I have to simulate large amount of unicode keyboard input into an old X11 application (of which I don't have any source access).
My program takes the input from an UCS-2 LE encoded input stream via stdin and the basic operation is as follows:
Save current keyboard layout and lock modifiers (XDisplayKeycodes, XGetKeyboardMapping, XkbGetState)
Unlock active modifiers (XkbLockModifiers)
Disable all X11 slave keyboard devices via Xinput2 extension
Read input into a key press queue until n unique symbols are encountered, where n is the number of possible keycodes as returned by XDisplayKeycodes.
Map these n unique X11 KeySyms via XChangeKeyboardMapping on the n available KeyCodes
Type the correct KeyCodes for all enqueued KeySyms via XTestFakeKeyEvent
Clear the queue and continue at 4.) until no input is available
Reactivate keyboards and restore initial modifiers and mappings
Basically this system works better and much more performant than any virtual X11 key input tool I've seen so far.
However, there is an issue I can currently only fix using ugly delays:
As any other X11 application, the target application receives a MappingNotify (request==Keyboard) event from the X server after my application succeeded in changing the keyboard mapping table.
The usual response of a X11 client is to call XRefreshKeyboardMapping to update Xlib's knowledge of the new keyboard layout.
Now if the the client has some lag processing its X11 event queue, the XRefreshKeyboardMapping call might return a too recent mapping that is already some generations too far in the future.
E.g. my input generator has already done the fourth XChangeKeyboardMapping when the target application just arrived at handling the second MappingNotify event in its XEvent queue handler.
Actually it should get the second generation of the map, which isn't available at the X server anymore at that time.
Unfortunately there is no map id or version of any kind in the keyboard MappingNotify event so that XRefreshKeyboardMapping could refer to a specific map ... and the X server does not seem to keep a history either.
The result is that the X11 application's KeyCode to KeySym conversion operates with an invalid layout and generates wrong KeySyms.
So basically I have to wait until all clients (or at least the one with the input focus) have requested and received my last XChangeKeyboardMapping map before I am allowed to do the next XChangeKeyboardMapping.
I can fix 99.9% of the errors using a delay before XChangeKeyboardMapping and that delay is calculated by some ugly witchcraft (amount of key strokes etc.) and is way to high if 100% accuracy has to be achieved.
So my question is if there is any way to programmatically be notified or to check if a X11 client has completed XRefreshKeyboardMapping or if its map is in sync with the server map?
If not, is there a way to get another X11 client's current mapping via xlib (to check if the map is current)?
Thanks for any hints!
I've done something similar on Windows in the past. I had the luxury of being able to use the SendInput function which accepts a KEYBDINPUT structure with KEYEVENTF_UNICODE flag. Unfortunately X11 does not support direct keystroke synthesizing of Unicode characters.
Since I cannot comment yet I'm forced to give a suggestion as answer:
Have you considered using the clipboard instead in order to transfer your "unicode input" into this X11 application's input field ?
You also might consider using direct Unicode input if that application uses a toolkit that supports this:
E.g. programs based on GTK+ (that includes all GNOME applications) support Unicode input.
Hold Ctrl + Shift and type u followed by the Unicode hex digits and release Ctrl and Shift again.
I guess it should be easy to synthesize these sequences using the Xtest extension.
Is there a way to check for dead keys in the current layout? I am currently capturing the users input for a project I am doing. I created a map of all keys on the keyboard, but there seems to be no flag or whatsoever defining a key as dead or not. I use libxkb in my current code.
The layout is retrieved using
KeySym * keysyms = XGetKeyboardMapping(display_, keycode_low, keycode_high - keycode_low + 1, &num_keysym);
I understand you need to know which key will not directly produce a character, maybe because you are writing a game and do not want to have it use keys as input that would require another key to be pressed to produce some output (if so, please mention in the question)
Not through standard Xlib calls, to my knowledge, and definitely not without actually pressing the respective key. Composing is entirely done within Xlib, and transparent to the front end. (For its original purpose, it should be as transparent as possible to work properly, after all)
You could, however, do the same thing that Xlib does and parse through the various Compose configuration files starting with $HOME/.Xcompose. But that could be a tedious process.
On second thought, I am definitely not proposing the following:
You could, for each key you are looking for information, create a synthetic keypress event and feed it into XLookupString. Hand in an emptied XComposeStatus structure as well. If the structure returns modified, this could be a strong hint you have found a compose key. But it could also mean the server modifies it without any need..... If I were very desparate, I'd probably try.
I'm trying to get a .net 2 Windows.Forms application running on the Mac using Mono. The application has key combination short cuts for all functions, which have pre-defined defaults and can be reconfigured by the user. The Form KeyDown event handler looks up the action to be performed.
My problem is relating the Modifiers and KeyCode to the actual keys pressed. I don't mind if some mapping needs to be added for the Mac, but I need at least 3 modifier keys. However of the 4 modifiers on the Mac, few seem to produce obvious results. I get:
Shift - works as expected
Ctrl - reports a different KeyCode, but with correct modifier (eg Ctrl+N has Modifiers = Control and KeyCode 14 = "RButton, Clear").
Alt - reports some other key, unmodified (eg Alt+R gives KeyCode = 168 = "BrowserRefresh")
Cmd - reports as Alt with expected KeyCode (eg Cmd+N appears as Alt-N)
I presume that the Cmd key would normally be used where Ctrl is used on Windows. Can anyone advise which of the three Mac keys I should be trying to use? And most importantly how to parse the KeyEventArgs to consistently report a base key plus three optional modifiers?
Mono is the latest version (as of a week or two ago), and it's a MacBook Air, OS X 10.8.1 if that makes any difference.
I get the same issues. Try using IRC and asking at irc.gnome.org on rooms Mono and MonoMac. Very helpful folks.
Apparently with MonoMac, which lets you build a native UI in Interface Builder and helps stub out your backend C# code to talk to it (that is, MonoMac is Mono talking to native Mac, not Mono running on a Mac; the second is just plain Mono), Windows.Forms support has dropped to the wayside -- I was told that Windows.Forms is essentially "dead" on the Mac, and the quiet bugzilla page seems to support that. It really is quite buggy. I ran into SelectionBackColor not working in RichTextBox right off the bat, then menu accelerators not working reliably. Windows.Forms on Mac is alpha to beta quality, I think.
That said, for what's essentially a labor of love, a surprising amount of Windows.Forms works well, but I wouldn't use it for a polished app. Good luck.
EDIT: I realize the OP wasn't specifically talking about menuitems, but here's a bug report about accelerators and menu items not working so well, just to speak to related bugginess.
[Mono-bugs] [Bug 75996][Maj] New - menuitem event not triggered by Shortcut
Windows.Forms on Mono is so close to working, it's tempting to think it's going to support what you need to get done, but, imo, to consider it solid enough for use beyond making quick utilities would be a mistake.
In case it's useful to anyone, this is where I ended up:
I eventually managed to hack my way around this particular 'feature' by creating a new KeyData value to replace the one provided by the event (this code running only if it's a Mac).
I swapped round some of the modifiers to make it more consistent with windows (ie if Cmd was pressed, and reported as Alt by Mono I changed that to Ctrl). I also filtered out ctrl+A to ctrl+Z which return KeyCodes 0 to 25 (not 65 to 90) and replaced these with their normal values.
Fortunately my code only wanted the KeyData. It wouldn't be possible to create a new KeyEventArgs using the updated data, since Mono checks the current keyboard state and sets modifier flags for any pressed modifier keys, in addition to any modifiers passed to the KeyEventArgs constructor.
BUT - as ruffin commented Mono on the Mac is very flaky. We've parked this work for the moment as it's taking quite a bit of time to work around all the problems. So far we've managed to find a solution for each item we've looked at, and may well come back to this - but at best it will be a nasty hack to get this S/W running on the Mac.
I'm trying to make a small game using (free)GLUT. I know that it's old and there are better alternatives, but currently I prefer to stick with it and use it as much as possible. I program with C.
I'm currently trying to make GLUT detect properly all the keys I press.
I use glutKeyboardFunc, glutKeyboardUpFunc, glutSpecialFunc and glutSpecialUpFunc to detect pressed keys and I store their state in a short array I created (I currently have only 5 usable keys, so I just created a specific array for them).
However, while everything works fine for 2 keys or less, the game doesn't detect properly 3 keys or more. While for some keys it detect the combination properly (that actually happens for only 1 specific combination), for others the functions simply don't detect the third key that I press.
I checked my code a few times, and there is nothing special about the combination that does work.
I also made glutKeyboardFunc and glutSpecialFunc directly print every key-press that they receive, and it seems they simply stop working after I press more then 2 keys.
Is it a known issue with GLUT or something? I googled a lot and didn't find anyone with a similar issue.
I am not very into GLUT but as I know, but you should make sure, that your keyboard supports more than 2 input keys at once. This feature is called n-key rollover. This page says, that 2-key rollover may be a common value for some keyboards, but you dont need to trust this source.
I'll clarify a point: The glutKeyBoardFunc is a callback i.e., it is invoked for every key pressed and re-executed over and over again and all the if-else (or switch-case) statements for various key combinations are executed. What it means is this - if you were to press 'A', '->' (right arrow) and 'D' all at once, depending on which key-press event was received first the callback will be executed accordingly. Sometimes with a delay and sometimes the on screen animation may stop momentarily.
GLUT is purely for educational/learning purposes but not good for full blown applications since that's not what it was designed for. You land up using OS specific libs or other languages (e.g., Qt) to embed OpenGL "window" within them and execute the keyboard events etc., The event handling in those (and/or OS specific frameworks) is radically different (and better) than GLUT.
You may want to keep your simultaneous key presses to a minimum. You may augment it with the mouse to get rid of the jerky response/processing...
I've tried Key.Subtract but I think that is the numpad version. I'm looking for the one after the zero key.
I wish to handle it in a KeyDown event.
Thanks
A quick debug shows the that it comes through as Key.Unknown as do other keys such as [ and ]
So it looks like you can't (easily) distinguish when this key is pressed.
The MSDN page for System.Windows.Input.Key enumeration lists all the values, which is significantly shorter than the .NET framework version.
However, if you look at e.PlatformKeyCode this might give you the value you need. However, the help for this states:
This value is the nonportable key code, which is operating system–specific.
The remarks are more extensive:
The portable key codes are a common subset of all the possible key codes of the supported operating systems, in this case, Macintosh and Windows. For example, the keystroke 'v' is represented as a Key value (which would evaluate as 51 if you cast it to an integer, but is more useful if you retain the enumeration information). That key would have a PlatformKeyCode value of 86. Certain keystrokes, however, are not portable, such as the SCROLL LOCK key for Microsoft Windows. In this case, the Key value is Unknown, which is the value for any nonportable key, and the PlatformKeyCode is 145 on a Windows platform. For information about Microsoft Windows-specific key codes, see "Virtual-Key Codes" in the MSDN Library. For information on Macintosh-specific key codes, see Keyboard Layout Services Reference (broken link removed) on the Apple Developer Connection Web site.
On my setup (Chrome in Windows XP) "-" is 189