Обходной путь Linux и XKB для дополнительного события Control_L при нажатии AltGr на рабочем столе Linux через VMWare Horizon

Я пытаюсь найти решение проблемы с клавиатурой при подключении к рабочему столу Linux с помощью VMWare Horizon View. Проблема кажется известной и была описана в 2012 году на База знаний VMWare, доступная на archive.org.. Должен добавить, что я мало знаю о том, как работает XKB, поэтому изучение этого было для меня полезным опытом.

Обходные пути, перечисленные в базе знаний VMWware, не являются удовлетворительными. Я могу подтвердить данное описание, что есть дополнительный нежелательный Control_L характер, когда я ударил AltGr. Когда я нажимаю AltGr+7, я ожидаю {, но вместо этого я получаю escape-символ 0x1b. Вот как это выглядит при запуске xev и нажатии AltGr+7 (ISO_Level3_Shift — это ожидаемое нажатие клавиши при нажатии AltGr).

Событие KeyPress, серийный номер 37, синтетический NO, окно 0x3000001,
    корень 0x521, subw 0x0, время 2444939915, (157,43), корень: (388,257),
    состояние 0x0, код клавиши 37 (символ клавиши 0xffe3, Control_L), тот же_экран ДА,
    XLookupString дает 0 байтов: 
    XmbLookupString дает 0 байтов: 
    XFilterEvent возвращает: False

Событие KeyPress, серийный номер 37, синтетический NO, окно 0x3000001,
    корень 0x521, subw 0x0, время 2444939920, (157,43), корень: (388,257),
    состояние 0x4, код клавиши 108 (символ клавиши 0xfe03, ISO_Level3_Shift), тот же_экран ДА,
    XKeysymToKeycode возвращает код ключа: 92
    XLookupString дает 0 байтов: 
    XmbLookupString дает 0 байтов: 
    XFilterEvent возвращает: False

Событие KeyPress, серийный номер 37, синтетический NO, окно 0x3000001,
    корень 0x521, subw 0x0, время 2444944595, (157,43), корень: (388,257),
    состояние 0x84, код клавиши 16 (keysym 0x7b, braceleft), same_screen YES,
    XLookupString дает 1 байт: (1b) "
mbLookupString дает 1 байт: (1b) "
FilterEvent возвращает: False

Событие KeyRelease, серийный номер 37, синтетический NO, окно 0x3000001,
    корень 0x521, subw 0x0, время 2444944763, (157,43), корень: (388,257),
    состояние 0x84, код клавиши 16 (keysym 0x7b, braceleft), same_screen YES,
    XLookupString дает 1 байт: (1b) "
FilterEvent возвращает: False

Событие KeyRelease, серийный номер 37, синтетический NO, окно 0x3000001,
    корень 0x521, subw 0x0, время 2444951582, (157,43), корень: (388,257),
    состояние 0x84, код клавиши 37 (символ клавиши 0xffe3, Control_L), тот же_экран ДА,
    XLookupString дает 0 байтов: 
    XFilterEvent возвращает: False

Событие KeyRelease, серийный номер 37, синтетический NO, окно 0x3000001,
    корень 0x521, subw 0x0, время 2444951586, (157,43), корень: (388,257),
    состояние 0x80, код клавиши 108 (символ клавиши 0xfe03, ISO_Level3_Shift), тот же_экран ДА,
    XKeysymToKeycode возвращает код ключа: 92
    XLookupString дает 0 байтов: 
    XFilterEvent возвращает: False

В базе знаний VMWare есть предложение нажать AltGr, а затем нажмите и отпустите левую Ctrl чтобы вызвать событие KeyRelease для Control_L, после чего я могу нажать 7 и получить вывод, который я ищу: XLookupString/XmbLookupString в этом случае возвращает 7b, что { как и ожидалось.

Итак, после подтверждения проблемы, я искал обходные пути в Linux. я побежал хкбкомп чтобы получить определение живой раскладки, запустив:

xkbcomp $DISPLAY out.xkb

После просмотра сгенерированного out.xkb, я подумал, что можно переопределить мои сопоставления клавиш, чтобы ожидать Control_L в дополнение к другим клавишам. Итак, чтобы выбрать некоторые важные части, мой файл out.xkb содержал:

xkb_types "полный" {
...
  введите "FOUR_LEVEL" {
    модификаторы= Shift+LevelThree;
    карта[Shift]= Уровень2;
    карта[LevelThree]= Уровень3;
    карта[Shift+LevelThree]= Уровень4;
  };
};
...
xkb_symbols "ПК+нет+inet(evdev)" {
...
  клавиша <AE07> {
    тип = "FOUR_LEVEL",
    символы [Группа1] = [ 7, косая черта, скобка влево, деление ]
  };
...
}

Левая скобка в приведенном выше определении - это то, что я пытаюсь заставить работать прямо сейчас.Моя идея заключалась в том, чтобы просто переопределить FOUR_LEVEL, чтобы в соответствующих случаях ожидать Control_L, например так:

  введите "FOUR_LEVEL" {
    модификаторы = Shift+LevelThree+LControl;
    карта[Shift]= Уровень2;
    карта[LevelThree+LControl]= Уровень3;
    карта[Shift+LevelThree+LControl]= Level4;
  };

Я создал сопоставление с этой настройкой, а затем попытался скомпилировать и загрузить свой измененный файл:

xkbcomp ctrl-hack.xkb
xkbcomp ctrl-hack.xkm $DISPLAY

К сожалению, мои изменения не работают так, как я надеялся. Я не получаю никаких ошибок, но я все еще получаю 0x1b вместо { символ, когда я нажимаю AltGr+7. Что может пойти не так?

Кроме того, я вижу, что некоторые другие символы (например, ¬ и $), кажется, работает, несмотря на то, что также требует AltGr модификатор и получение дополнительного неожиданного Control_L. Но тестируя при ручном нажатии Control_L, я вижу, что ¬ работает как с нажатой клавишей Control_L, так и без нее, поэтому, похоже, для этого символа есть какое-то резервное определение, которое не указано явно в хкбкомп вывод. Я еще не понял, как это работает. Можно ли определить аналогичные запасные варианты для символов, которые мне не хватает? Возможно, какое-то наследство от конфигурации клавиатуры консоли, например? Это, вероятно, произошло бы из того же места, что и 0x1b символ, который я получаю при нажатии Ctrl-AltGr-7. Я не могу найти его в XKB-config, поэтому он должен быть определен где-то еще.