Hello,
I was writing an automation script on Ubuntu 18.04 using python-xlib when I noticed that keycode returned by the Display.keysym_to_keycode() for < wasn't what I expected.

Code snippet:

...

display = Xlib.display.Display(os.environ['DISPLAY'])

def print_keycodes(key_string):
    """ Prints keycodes from keystrings """
    keysym = Xlib.XK.string_to_keysym(key_string)
    print(
        f'> For {key_string}\t: '
        f'Keycode = {display.keysym_to_keycode(keysym)},  '
        f'Keycodes = {display.keysym_to_keycodes(keysym)}'
        )

for key_string in ('comma', 'less', 'period', 'greater'):
  print_keycodes(key_string)

Output:

For comma	: Keycode = 59,  Keycodes = [(59, 0), (59, 2)]
For less	: Keycode = 94,  Keycodes = [(94, 0), (59, 1), (94, 2), (59, 3)]
For period	: Keycode = 60,  Keycodes = [(60, 0), (60, 2)]
For greater	: Keycode = 60,  Keycodes = [(60, 1), (94, 1), (60, 3), (94, 3)]

As per my understanding, keysym_to_keycodes() returns a list of tuples in (keycode, index) format where the index 0 is unshifted, 1 is shifted, 2 is alt-grid, and 3 is shift+alt-grid and the method keysym_to_keycode() returns the first keycode from the same list.

Since period(.) and greater(>) are typed using the same key on a keyboard, it makes sense that the code returned by keysym_to_keycode() is same for both i.e. 60 where former is unshifted and the latter requires pressing the shift key too.

Questions: Shouldn't the same apply to comma(,) and less(<) as well ? Shouldn't the codes returned for both of them be 59 where former would be unshifted and the latter would be shifted? What does (94, 0) represent ? Is it for a different keyboard layout ?

[Ubuntu 18.04] [python 3.6.9]

I'm new to Xlib and there can be gaps in my understanding, but I find this inconsistent. Can someone please confirm if this is the expected behavior or am I missing something ? Any help would be appreciated.

Thanks,
Sagar Bhat