Recent

Author Topic: Physical keys to generate shift states ssSuper and ssHyper  (Read 5510 times)

LongTimePascaler

  • New Member
  • *
  • Posts: 20
Physical keys to generate shift states ssSuper and ssHyper
« on: July 22, 2019, 01:54:32 pm »
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

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #1 on: July 22, 2019, 02:19:54 pm »
(did you also try right alt?)

LongTimePascaler

  • New Member
  • *
  • Posts: 20
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #2 on: July 22, 2019, 02:23:41 pm »
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

  • Hero Member
  • *****
  • Posts: 4219
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #3 on: July 22, 2019, 04:02:44 pm »
Is 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 ...
« Last Edit: July 22, 2019, 05:03:35 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

LongTimePascaler

  • New Member
  • *
  • Posts: 20
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #4 on: July 22, 2019, 05:37:25 pm »
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

  • Hero Member
  • *****
  • Posts: 4219
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #5 on: July 22, 2019, 05:50:56 pm »
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 :D

Now I think about it, it might be interesting to test in Windows and MacOS and see the differences (if any).
« Last Edit: July 22, 2019, 05:52:56 pm by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

lucamar

  • Hero Member
  • *****
  • Posts: 4219
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #6 on: July 23, 2019, 01:03:47 am »
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][+][-]
  1. uses LazLogger, LCLProc, LCLType;
  2.  
  3. procedure TMainForm.FormKeyDown(Sender: TObject; var Key: Word;
  4.   Shift: TShiftState);
  5. const
  6.   DontIgnore =
  7.       [VK_RETURN, VK_PRIOR, VK_NEXT, VK_END, VK_HOME, VK_LEFT,
  8.       VK_UP, VK_RIGHT, VK_DOWN, VK_INSERT, VK_DELETE];
  9. var
  10.   sv: String;
  11. begin
  12.   sv := Format('Key: %s - Shift: %s', [DbgsVKCode(Key),DbgS(Shift)]);
  13.   if Key in DontIgnore then
  14.     StatusBar.SimpleText := sv
  15.   else begin
  16.     Memo.Lines.Add(sv);
  17.     Key := $00;
  18.   end;
  19. end;
« Last Edit: July 23, 2019, 01:17:04 am by lucamar »
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

LongTimePascaler

  • New Member
  • *
  • Posts: 20
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #7 on: July 23, 2019, 08:58:52 am »
Quote
Now 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.
Quote
For the technically curious, this is the code producing that output
Thanks 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

  • New Member
  • *
  • Posts: 20
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #8 on: July 24, 2019, 02:39:29 pm »
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

  • Hero Member
  • *****
  • Posts: 4219
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #9 on: July 24, 2019, 04:19:08 pm »
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 :D
Turbo Pascal 3 CP/M - Amstrad PCW 8256 (512 KB !!!) :P
Lazarus/FPC 2.0.8/3.0.4 & 2.0.12/3.2.0 - 32/64 bits on:
(K|L|X)Ubuntu 12..18, Windows XP, 7, 10 and various DOSes.

LongTimePascaler

  • New Member
  • *
  • Posts: 20
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #10 on: July 24, 2019, 05:46:07 pm »
Quote
Those 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.
« Last Edit: July 24, 2019, 06:10:22 pm by LongTimePascaler »

MarkMLl

  • Hero Member
  • *****
  • Posts: 6676
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #11 on: October 04, 2019, 11:21:49 am »
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
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

winni

  • Hero Member
  • *****
  • Posts: 3197
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #12 on: October 04, 2019, 02:32:12 pm »
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 type
Code: Bash  [Select][+][-]
  1.  
  2. localectl list-keymaps

I've got more than 500 maps on my PC!

Then have a look at

Code: Bash  [Select][+][-]
  1. /usr/share/kbd/keymaps/legacy/i386/qwertz
  2.  
  3.  

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][+][-]
  1. keycode  54 = Shift
  2. keycode  56 = Alt
  3. keycode  57 = space            space            Meta_space      nul
  4. keycode  58 = Caps_Lock
  5.  

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_configuration

Happy §4^/!

Winni



LongTimePascaler

  • New Member
  • *
  • Posts: 20
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #13 on: October 04, 2019, 06:42:41 pm »
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

  • Hero Member
  • *****
  • Posts: 3197
Re: Physical keys to generate shift states ssSuper and ssHyper
« Reply #14 on: October 04, 2019, 07:14:03 pm »
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

 

TinyPortal © 2005-2018