Physical keys to generate shift states ssSuper and ssHyper lazarus / 66-Unix ---------------------------------------------------------------------- LongTimePascaler · 2019-07-22 11:54 I have a standard Microsoft-type keyboard but am running Linux.  The Windows key generates the shift state ssMeta.  I cannot find any key or key combination that will generate shift states ssSuper or ssHyper.  Browsing the Lazarus source code didn't help and a simple program to capture key presses likewise got me no closer.  Is it possible to generate ssSuper and ssHyper or am I chasing something that doesn't exist? ---------------------------------------------------------------------- marcov · 2019-07-22 12:19 (did you also try right alt?) ---------------------------------------------------------------------- LongTimePascaler · 2019-07-22 12:23 Quote(did you also try right alt?) My keyboard has Alt on the left side and AltGr on the right side.  Both map to ssAlt.  There is a shift state ssAltGr but it isn't generated by my AltGr key. ---------------------------------------------------------------------- lucamar · 2019-07-22 14:02 Quote from: LongTimePascaler on July 22, 2019, 01:54:32 pmIs it possible to generate ssSuper and ssHyper or am I chasing something that doesn't exist? It does exist but depends quite heavily on the active keyboard map and there is, AFAICT, no standard mapping for those shift states. In this machine, for example, with the "normal" es-ES map the "Windows" key generates ssSuper ssMeta but with the es-ES.traditional it generates nothing at all. ETA: Not ssSuper, ssMeta! Slip of the tongue ... EATA: Curiously enough, the global shortcuts' editor thinks that key (the "Windows" key) is "Super". Queer doings somewhere ... ---------------------------------------------------------------------- LongTimePascaler · 2019-07-22 15:37 Queer things indeed.  My locale is en_GB.UTF-8.  So if the shift states are tied to the keyboard mapping, it seems that I can generate ssMeta and ssAlt but not ssAltGr, ssSuper nor ssHyper with the keyboard mapping that is implied by that locale.  I don't want to change the environment set-up for the sake of one piece of software so, unless someone can suggest anything else, I'll have to assume only ssAlt and ssMeta will ever need to be handled in the code. ---------------------------------------------------------------------- lucamar · 2019-07-22 15:50 That's what I do. Basically because my programs usually care for very specific combinations and ignore all the rest and I use nothing more than ssCtrl, ssShift and ssAlt. Although I do have a test program that shows what combination one typed: that one does't ignore any key or shift-state Now I think about it, it might be interesting to test in Windows and MacOS and see the differences (if any). ---------------------------------------------------------------------- lucamar · 2019-07-22 23:03 I remembered (nebulously) something so I've modified a little my test program and I've confirmed that the shift keys do produce an OnKeyDown event by themselves, so it's possible to use that fact to know that a key with ssMeta in its shift-state is in fact in combination of the "Windows" key. It's not as nice as having it produce a ssSuper or ssHyper but if you need it ... See attached image to see the couple KeyDown events produced: the first when pressing the "Win" key and the second when pressing the "A" key. ETA: For the technically curious, this is the code producing that output: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i uses LazLogger, LCLProc, LCLType; procedure TMainForm.FormKeyDown(Sender: TObject; var Key: Word;  Shift: TShiftState);const  DontIgnore =      [VK_RETURN, VK_PRIOR, VK_NEXT, VK_END, VK_HOME, VK_LEFT,      VK_UP, VK_RIGHT, VK_DOWN, VK_INSERT, VK_DELETE];var  sv: String;begin  sv := Format('Key: %s - Shift: %s', [DbgsVKCode(Key),DbgS(Shift)]);  if Key in DontIgnore then    StatusBar.SimpleText := sv  else begin    Memo.Lines.Add(sv);    Key := $00;  end;end; ---------------------------------------------------------------------- LongTimePascaler · 2019-07-23 06:58 QuoteNow I think about it, it might be interesting to test in Windows and MacOS and see the differences (if any).It would be, but at the moment I only operate in a Linux universe so I don't have any machines to investigate that. QuoteFor the technically curious, this is the code producing that outputThanks for providing that. Before posting I also had a little test program to print out the values of key (as a Word rather than a Char) for the OnKeyDown event and compared those with the output of xev.  There isn't much (any?) relationship between those values, assumedly because FreePascal/Lazarus maps values to those (very) old Windows VK_ values. For example: xev gives: Alt as 64, AltGr as 108, left Windows key as 133, right Windows key as 134 Lazarus gives: Alt as 18 (ssAlt), AltGr as 228 (ssAlt), left Windows key as 91 (ssMeta), right Windows key as 92 (no shift state) I'd quite like to see where the values delivered to Lazarus are mapped to VK_ key values and ultimately shift states, but at the moment I don't have the energy or enthusiasm sufficient to plough through the source code.  It isn't even clear where Lazarus is getting the values from.  My Lazarus form is covered by an OpenGL control, and a Lazarus form is in any case a window provided by the desktop environment (in my case KDE/Plasma) with a little help from a toolkit (I use the default Lazarus built on Gtk); KDE sits on X11 and everything is on top of Linux, so ... somebody must know where raw key codes are mapped to shift states, but that somebody isn't me. ---------------------------------------------------------------------- LongTimePascaler · 2019-07-24 12:39 The weirdness just gets weirder.  I haven't tested all possibilities but what I've found is summarised in the following table: Physical Key       |               Shift State for events:                    +-----------------------------------------------------------                    | KeyDown   KeyUp    MouseDown     MouseUp        MouseWheel -------------------+-------------------------------------------------- --------- Left Shift         | ssShift     ─      ssShift       ssShift                    | Left Ctrl          | ssCtrl      ─      ssCtrl        ssCtrl         ssCtrl                    | Left Windows       | ssMeta      ─      ssMeta        ssMeta         ssSuper                    | Alt                | ssAlt       ─     (no mouse event delivered)    ssAlt                    | AltGr              | ssAlt       ─      ssAlt         ssAlt          ssAltGr                    | Right Windows      |  ─        ssMeta   ssMeta        ssMeta         ssSuper                    | Right Ctrl         | ssCtrl      ─      ssCtrl        ssCtrl         ssCtrl                    | Right Shift        | ssShift     ─      ssShift       ssShift        ssShift                    |                    | Left Shift + Alt   | ssShift ssAlt      ssShift ssAlt                    | Left Ctrl + Alt    | ssCtrl ssAlt       ssCtrl ssAlt                    | Left Windows + Alt | ssMeta ssAlt       ssMeta ssAlt -------------------+-------------------------------------------------- --------- where '─' means the shift state was empty and a blank cell means I haven't tested that; indicators for the mouse buttons (ssLeft, ssMiddle and ssRight) are ignored in the table. I can see no rhyme nor reason in these values.  If someone can explain it I'd be grateful.  But perhaps they simply reproduce what Delphi delivers, so that this (apparently undocumented) behaviour is just something to be aware of and to be accounted for. And there is indeed a circumstance when ssSuper will be in the shift state, so now we know. ---------------------------------------------------------------------- lucamar · 2019-07-24 14:19 Those are for the shift keys by themselves or combined with some other key? They look quite reasonable (for certains values of "reasonable" ... let's say "coherent", instead ): Alt keys produce ssAlt, Shift produces ssShift, meta keys (the Win ones) ssMeta, and so on without regard to whether they are the rigth or left key. Except for RWindows which seems to be head-over-heels. A bit stranger is the behaviour with the mouse wheel: looks like there it's regarding each specific key instead of subsumming like-with-like, as if they were not "translated" like in the other cases. Maybe it was added much later by someone else? All in all, though, quite a useful chart. Saved it to the "interesting things" folder ---------------------------------------------------------------------- LongTimePascaler · 2019-07-24 15:46 QuoteThose are for the shift keys by themselves or combined with some other key? Apart from the last three lines of the table they are all a single key plus a mouse button or the mouse wheel.  The only way I could find to get the Alt key to generate ssAlt is in combination with another key.  I'm not sure why Alt+mouse button does not generate a mouse event.  Then there is the matter that AltGr generates ssAlt for mouse buttons down but ssAltGr for the mouse wheel, and the Windows key generates ssMeta for mouse buttons down but ssSuper for the mouse wheel.  And the difference in OnKeyDown and OnKeyUp events with the left and right Windows keys too. I'm pleased you find it useful information, and I hope others do too.  But now I must get on with writing the interface I was trying write when I was befuddled by all this. ---------------------------------------------------------------------- MarkMLl · 2019-10-04 09:21 Part of the problem is that there are several stages involved: * Keyboard hardware * HID report descriptor (not always reliable) * Device-specific "quirks" code to fix the HID * Kernel-level events codes * X11 * Widget set Only then do you get to the LCL. I've had to hack at this sort of thing quite a lot to satisfy a particularly bloody-minded user. I suggest that you start off with evtest to see what the keyboard/kernel are generating. MarkMLl ---------------------------------------------------------------------- winni · 2019-10-04 12:32 Hi! As Lucamar said: trouble with the keyboard in Linux are at 99% trouble with  the keymap and not hardware trouble. If you use a widespread  language then there is more then one keyboard map. So you might test another map. To list all keymaps installed on your Linux system typeCode: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i  localectl list-keymaps I've got more than 500 maps on my PC! Then have a look at Code: Bash  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i /usr/share/kbd/keymaps/legacy/i386/qwertz   The table without suffix .gz is in use There you will find all physical keys mapped to software event. A small part: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i keycode  54 = Shiftkeycode  56 = Altkeycode  57 = space            space          Meta_space      nulkeycode  58 = Caps_Lock  So you can map any key to any event. I once saw a "10 finger queen" on a Linux system. She had swapped the Windows and Shift Keys. She argued the way to the Windows keys is shorter. A good page where the whole keyboard stuff is good described is this page https://wiki.archlinux.org/index.php/Linux_console/Keyboard_configurat ion Happy §4^/! Winni ---------------------------------------------------------------------- LongTimePascaler · 2019-10-04 16:42 Thanks MarkMLl and winni for responding. @MarkMLl: I hadn't heard of evtest before and when I investigated I found that the author released a new program a few years back, namely evemu (https://www.freedesktop.org/wiki/Evemu/; http://who-t.blogspot.com/2013/11/evtest-is-dead-long-live- evemu.html), that he prefers we use.  I used evemu with a little test program that just captures key down events. In the end I'm not sure it told me any more than I could get from /usr/include/linux/input-event-codes.h, although I can see it could be quite useful for automating test cases. @winni: I have worked around the uncertainty over key combinations for now and moved on to other things, but along the way I did realize that keymaps are involved too, but in unpredictable ways not least because I still don't know from which layer the LCL gets its event information.  As an example of why I say unpredictable:  on one of my machines Linux and X know my keyboard has the GB layout but KDE Plasma has firmly decided that it is the US layout and I can't find any way of disabusing it of that notion (other than resetting the keymap every time I log in), which is quite annoying. (KDE Plasma is consistent with X and Linux on the other machines.) I'll probably have to return to this issue before the code goes into production but for the moment hunting down memory leaks is the priority. ---------------------------------------------------------------------- winni · 2019-10-04 17:14 Hi! I just changed with some few clicks my default language from german to british english on mmy KDE Plasma: system settings --> regional settings --> Language If you got only one language you must add a second with "Add languages" Click the desired language and "Apply" Logout from the desktop and in again:  everything in british. Works fine without problems. Winni ---------------------------------------------------------------------- LongTimePascaler · 2019-10-07 10:39 Thanks winni. This is getting off-topic, but: the region was already set to British English so I added a second language and selected British English.  It made no difference.  The only way that I've found to correct it is to revisit system settings -> input devices -> keyboard and hardware layout -> layouts, and then unclick and re-click the configure layouts with gb english selected.  It shouldn't be necessary -- Plasma shouldn't be being so bloody minded -- which is why I think it's something to raise on a KDE forum rather than this forum.  But thanks for trying to help. ---------------------------------------------------------------------- Zvoni · 2019-10-07 12:36 Quote from: LongTimePascaler on October 07, 2019, 12:39:30 pmThanks winni. This is getting off-topic, but: the region was already set to British English so I added a second language and selected British English.  It made no difference.  The only way that I've found to correct it is to revisit system settings -> input devices -> keyboard and hardware layout -> layouts, and then unclick and re-click the configure layouts with gb english selected.  It shouldn't be necessary -- Plasma shouldn't be being so bloody minded -- which is why I think it's something to raise on a KDE forum rather than this forum.  But thanks for trying to help. I know, it's an old thread, but it sounds suspiciously like your problem. https://ubuntuforums.org/showthread.php?t=1793250 Have you tried to reconfigure keyboard-config AND console-setup (Post #8 in the link)? ---------------------------------------------------------------------- LongTimePascaler · 2019-10-07 17:47 Thanks for the suggestion Zvoni, but dpkg is a Debian utility and my distro is from the RedHat-type family.  I'll need to find out what the equivalent commands are in my environment. ---------------------------------------------------------------------- winni · 2019-10-07 18:03 Hi! I don't know if it's a good idea to replace "British English" with "British English". Think about the always used code Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i if newValue = oldValue then exit; Take another language to look if something changes. Red Hat has a very well online documentation: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux /7/html/system_administrators_guide/s1-changing_the_keyboard_layout But I don't know: Is it allowed for a European to use Red Hat??  ;-) Winni ---------------------------------------------------------------------- Zvoni · 2019-10-08 05:47 Quote from: LongTimePascaler on October 07, 2019, 07:47:04 pmThanks for the suggestion Zvoni, but dpkg is a Debian utility and my distro is from the RedHat-type family.  I'll need to find out what the equivalent commands are in my environment. Yum is the apt-get, rpm is dpkg (as far as i could find out) ---------------------------------------------------------------------- regs · 2025-04-10 12:06 Shouldn't this long standing issue be addressed somehow? With platform directives, for example. I understand there were some very rare keyboards with Meta, Super and Hyper keys some 45+ years ago, but modern Lazarus more oriented on Windows, Linux and BSD variations, where there are no Meta and Hyper keys, and Win key is Super key. And not just ShiftStates, but also TextToShortCut and ShortCutToText needs to be more universal. TextToShortCut needs to accept both Win and Super. May be use ssSuper by default in Windows and non-Darwin BSD leaving ssMeta as alias for compatibility with older code.