keyboard mapping issues when using non-US layout #4382
Comments
|
Not sure about a resolution to your problem but I know of tests that test a different keyboard layout, see |
|
That test seems to rely on the behaviour in question. Looking at the line where it types stuff, it actually types Similarly, if you hunt for the string |
|
The test referenced by @okurz does this:
So this test in fact relies on os-autoinst still using a (virtual) US keyboard all the time regardless of what the SUT expects. I suppose you're asking for a way to change the layout of os-autoinst's virtual keyboard from US to something else? It looks like @phil-hands I haven't seen your comment when I submitted this comment. |
|
@Martchus I think that's probably right. I suspect that setting KVMKB does most of what I want. If you ran that azerty/qwerty test with KVMKB=fr-fr (or whatever the default french keyboard layout is) then I would guess that it would display Just to make things awkward, the case I was caring about was the UK keyboard, and it seems that there are some assumptions about My hope would be that one could end up in a situation where one could write a test that has an BTW the One could kludge around it by having a function that takes a string and turns it into whatever one has to type in order to fool the SUT into thinking you typed that string, but this doesn't strike me as the most elegant solution to the problem ;-) |
|
Stupid question, but what's that |
|
Oops, sorry. BTW That's |
|
FWIW, in Fedora's instance we also kinda expect/rely on the "qemu is always emulating a US keyboard" behaviour. I think we actually wrote a version of the "not elegant" function @phil-hands suggests at some point, but I think we've factored that out since...we just have several places where we type the "right wrong thing" in French :) |
|
Additionally, Fedora has I've added british as an option, and done it in a way that still works in the Debian Installer environment (which does not include the US mapping file, so you need to create it). Obviously, I should change the french & german options to do the same The kludgy nature of this was another thing that prompted me to open this issue, since I can certainly imagine someone in Debian deciding that they want to really test alternate keyboard layouts, so I'd prefer to make something a bit more generally applicable if possible. |
|
@phil-hands if you want to poke at this, the code is mainly in os-autoinst VNC.pm starting at line 520. The docs for the "other end" are here. It does note, for instance, the issue you mention with keys that are shifted in some layouts but not in others: "The "shift state" (i.e. whether either of the Shift keysyms are down) should only be used as a hint when interpreting a keysym. For example, on a US keyboard the '#' character is shifted, but on a UK keyboard it is not. A server with a US keyboard receiving a '#' character from a client with a UK keyboard will not have been sent any shift presses. In this case, it is likely that the server will internally need to "fake" a shift press on its local system, in order to get a '#' character and not, for example, a '3'." I would assume qemu can do most of that handling, but I've never tested it. It's notable that there are actually two different ways we could send keypresses to qemu, here. The one we're using is the older, VNC-standard one ("KeyEvent"), where we (the VNC client) send a keysym (approximately, a value that represents a character, not a physical key) to the server (qemu). qemu supports an extension, "QEMU Extended Key Event Message", which allows passing both a keysym and a scancode, with the keysym optional ( It would, I think, at least be a more 'true' way to test alternate keyboard layouts extensively, if you really wanted to do that. |
|
BTW, I think I did experiment with |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
[sorry for leaving this fallow for a while ... I'd not forgotten about it, just been busy.] It seems to me that I need to add a function that allows one to set the mapping to use, such that if one calls something like However I'm a bit vague about how/where I'm supposed to add that in a way that makes it available via the testapi. It seems that the required mappings ought to be already defined somewhere (vnc? qemu? in the linux kernel?) in which case using that mapping as the basis of the conversion in KVM.pm would seem to be a way of doing it without having to hand-code a series of locale-based mappings in the style it's been done already for the US mapping.. Any suggestions on where to find the relevant info would be very welcome. |
|
I found key-mappings in the |
|
OK, so I have come across mappings in various places that seem like what's available there, but I discounted them because, for example, if one looks at the https://github.com/legionus/kbd/blob/master/data/keymaps/i386/qwerty/us.map#L36 you see that it's mapping decimal whereas in the VNC.pm file we see that the code for that key is https://github.com/os-autoinst/os-autoinst/blob/master/consoles/VNC.pm#L542 As another example, the This appears to be a distinction between scancodes and keycodes or some such, and I'd presume that there's a mapping from one to the other somewhere (in the linux kernel perhaps?) which one could use to generate the numbers we need in VNC.pm, probably by combining them with the mapping from the kbd-project, such that we wouldn't need to reinvent the wheel for each keyboard we're interested in supporting. |
|
Well, a few things. First of all those values you're looking at are from You do have to keep in mind the whole chain of what's happening here. Remember that ultimately we're talking to a VM, here. What qemu must ultimately do when we tell it to "press a key" is have the VM's virtual keyboard emit a keypress, which the guest OS's kernel will read as a keycode. The guest OS will then decide based on the layout configuration it's currently using what character to map that keycode to. Given the mechanisms at play here, it's not actually possible to tell qemu "just make this exact character appear on the VM's screen". We're always working at a more indirect level than that. What happens with our current mechanism is we tell qemu "press the A key". qemu then uses an internal US keyboard mapping to decide what physical key it should tell the VM was just pressed - i.e. it converts the keysym we sent it, So effectively speaking, what we're really telling qemu when we say "press the [something] key" is "press the key that's labelled [something] on a US keyboard". We do have the option of sending keycodes instead of keysyms to qemu, if we want. We can directly send the keycode As I figure it, we'd then have to keep code on the os-autoinst side to map from characters back to scancodes for every keyboard layout we want to support, and we'd have to have a mechanism for the test to keep track of what keyboard layout configuration it thinks the guest is currently using, so we'd know what layout to send the keycodes for when the test code says "press the a key". That seems like a lot of work that can all go wrong at some point. It's difficult with the current approach too, but it's not clear to me at least that changing from sending keysyms to keycodes would make it any less difficult. I think it's just inherently a hard problem. Sending keycodes instead of keysyms is obviously better if the agent using qemu is a real person typing on a real keyboard, because it avoids two whole layers of translation that can go wrong and just passes the code for the physical key the person pressed straight through to the guest OS to interpret. But in os-autoinst, there isn't a human typing on a physical keyboard, there's just test code that says "type this character". Which is unfortunately a rather complex operation when you unpick it. |
|
Oh, forgot to mention - what happens if you pass As I said, the problem I had with using this mechanism is that in practice, when we're testing non-US languages and layouts, the VM still has a US keyboard layout loaded until we actually reach the installer and change it to the native layout. If you set So if you need to edit kernel parameters in grub before the installer starts, or interact with the installer image's boot menu, or anything like that, you still have a problem. |
|
Another way to think about this mess: The interface we want for test code is "specify a string to send". We want test writers to be able to say "type the string 'banana'", not "send this string of obscure physical keycodes". But we cannot change the fact that what ultimately gets generated in the VM under test is a keycode for its guest OS to convert into a character. So, the "map this string of characters to a string of keycodes" step must happen. We only have the choice of letting qemu do it, or doing it ourselves. Whether we do it, or qemu does it, there's a tricky problem that needs solving: keeping track of what layout is currently configured in the guest, and making sure the string we send gets mapped to the keycodes that produce the desired output string with that layout. Currently the way we're mostly doing this, I think, is by "typing things wrong": when we want to test a non-US layout, we just use 'wrong' strings that we know cause the correct keycodes to be emitted. So if we know the guest OS has a French layout loaded, we know to tell qemu to hit the "q" key when we want the guest OS to get an "a": we use AFAICS, there are theoretically two other choices there:
|
|
Thanks for the lengthy but enlightening comments. I suppose the first step is to check whether there's a qmp command. If we needed to do the mapping on our own we could likely make use of existing keymappings (although we'll have to use them the other way around). I'm wondering whether it is worth it considering that testing another layout is usually not done very extensively and "typing it wrong" was sufficient so far. |
|
Yeah, that's kinda broadly my take. Plus I feel like the way we actually implement os-autoinst tests - with lots of reuse of modules in different contexts - it'd actually be quite tricky to do the "keep the guest layout and os-autoinst mapping in sync" part in practice, that feels like it'd get a bit bear trap-y. The current options ( |
|
well...hmm...I suppose it should be workaroundable, actually. If you want to type a so basically the challenge is: set the guest OS to the UK keyboard layout, then type a The question is whether there's a keysym you can send qemu when it's using its "us" conversion mode which will produce the keycode for that "extra" key (referred to as "INT1", it seems). I think that keycode is 86 - it's defined in It looks like qemu's en-us mapping does map that keycode, although AFAIK there is no official standard definition of what that key "should be" on a US keyboard. qemu decides it would be a key that types a "less than" character unshifted, a "greater than" character shifted, a "bar" (I think that's a pipe) with altgr, and a "broken bar" (that's So. I think the solution to the challenge may be to send the keysym This is fun! I'm gonna test it out. |
|
Sorry about the long pause getting back to this. I just tried a test where a UK keyboard was selected when installing the SUT, and VNCKB is not set. I then had it \\ hash # tilde ~ s-quote ' d-quotes \" at @ pipe | \n \\ backslash \\ grave ` lt < gt > \n which gives one the following results: Without pipe, I guess the solution (which I already use) is to tell the SUT that it should switch to a US mapping before doing anything complicated in a script. I was hoping that there would be a way of getting type_string to do the right thing regardless of the currently active mapping, but it looks like the benefit isn't worth the effort (particularly if one has to hand-code things for each different keyboard setting) BTW adding any of Reason: backend died: No map for '�' at /usr/lib/os-autoinst/consoles/VNC.pm line 740. |
|
BTW one aspect of this that bites when one is using a UK mapping on the SUT is that my $cmd = "curl --form upload=\@$file --form upname=$upname "; but typing that I briefly wondered if one could use something like |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
This Pull Request has been automatically closed as it did not have any activity in the last 97 days. Thank you. |
|
Reopening as likely still valid. Also I created https://progress.opensuse.org/issues/117136 to prevent the stale bot to close issues which are still valid. |
|
yeah, this is still an interesting topic, but it's just not practically speaking very important so I can't justify getting back to it until I have nothing more important to work on :| don't know about phil. |
|
Thanks for that. However, I think being put in a position where I felt like I ought to put some more effort into this, and come up with something constructive to say before reopening it myself was probably quite motivating ... I've just not got round to actually applying that motivation, yet :-) |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Hi, I was dealing with some of the problems explained here and first I have to say this issue helped me a lot to understand what I was dealing with, so thanks. To say more about my skills in that matter, I learn Perl for the first time through openQA so excuse me in advance if I am wrong on certain things. But I would like to contribute and help maybe improving the way keyboard layouts are implemented from an openQA type_string function to a qemu virtual keyboard output on a VM display, here are some insights of what we had to do in my team : We test a custom preseeded debian ISO which from the beginning of the installation use the french language and a french keyboard layout. All inputs of our tests then need to obviously take this layout into account. With the VNCKB=fr set, we thought it would be enough but several things came on our path to resolution : The current state of openQA says (written inside the die handler function in the lib VNC.pm) that no other layouts than en-us are supported. sub die_on_invalid_mapping ($key) {
die decode_utf8 "No map for '$key' - layouts other than en-us are not supported\n";
}This explained that many character we tried to type didn't match even with the VNCKB=fr parameter set. Most of these wrong characters were at the top of the keyboard layout where numbers and special character accessible with shift are. So we had to edit this lib to bring support to the fr layout : As said even with the VNCKB=fr (which tells qemu to use a virtual keyboard with a french layout), we came through unattended issues : The lib VNC.pm includes a function called shift_keys which only handles the en-us layout and then type wrong any other keyboard layout. The errors seem to occure in a strangely manner until you know it is handled as a hard coded list of key/value matches 😃 . So we edited it as is : sub shift_keys () {
# see http://en.wikipedia.org/wiki/IBM_PC_keyboard
# see https://www.tcl.tk/man/tcl8.4/TkCmd/keysyms.html
# see https://www.ascii-code.com/fr
# see https://doc.ubuntu-fr.org/tutoriel/comprendre_la_configuration_du_clavier
return {
'1' => '&',
'2' => chr(233), # é est mal encodé donc on le désigne par chr(233)
'3' => '"',
'4' => '\'',
'5' => '(',
'6' => '-',
'7' => chr(232), # è est mal encodé donc on le désigne par chr(232)
'8' => '_',
'9' => chr(231), # ç est mal encodé donc on le désigne par chr(231)
'0' => chr(224), # à est mal encodé donc on le désigne par chr(224)
#'°' => ')',
chr(176) => ')', # ° est parfois mal encodé donc on le désigne par chr(176)
'+' => '=',
# second line
#'"' => '^', # trema buggué car boucle avec les double quote
#'£' => '$',
chr(163) => '$', # £ est parfois mal encodé donc on le désigne par chr(163)
# third line
'%' => chr(249), # ù est mal encodé donc on le désigne par chr(249)
#'µ' => '*',
chr(181) => '*', # µ est parfois mal encodé donc on le désigne par chr(181)
# fourth line
'?' => ',',
'.' => ';',
'/' => ':',
#'§' => '!',
chr(167) => '!', # § est parfois mal encodé donc on le désigne par chr(167)
'>' => '<',
};
} for my $key (keys %{shift_keys()}) {
die_on_invalid_mapping($key) unless $keymap{$key};
$keymap{$key} = [$keymap{shift}, $keymap{$key}];
}while it could be my %shiftkeys=%{shift_keys()};
for my $key (keys (%shiftkeys)) {
die_on_invalid_mapping($key) unless $keymap{$key};
bmwqemu::diag "[Keytab Shift Keys] $key : [$keymap{shift},$keymap{$shiftkeys{$key}}]";
$keymap{$key} = [$keymap{shift}, $keymap{$shiftkeys{$key}}];
}making more sense to me... There aren't always matches between ASCII/UTF8 and keysym/keycode so it brings difficulties, and here are the steps we came through :
my $keymap_x11 = {
'esc' => 0xff1b,
'down' => 0xff54,
'right' => 0xff53,
'up' => 0xff52,
'left' => 0xff51,
'equal' => ord('='),
'spc' => ord(' '),
'minus' => ord('-'),
'shift' => 0xffe1,
'ctrl' => 0xffe3, # left, right is e4
'ctrlright' => 0xffe4,
'caps' => 0xffe5,
'meta' => 0xffe7, # left, right is e8
'metaright' => 0xffe8,
'alt' => 0xffe9, # left one, right is ea
'altgr' => 0xffea,
'ret' => 0xff0d,
'tab' => 0xff09,
'backspace' => 0xff08,
'end' => 0xff57,
'delete' => 0xffff,
'home' => 0xff50,
'insert' => 0xff63,
'pgup' => 0xff55,
'pgdn' => 0xff56,
'sysrq' => 0xff15,
'super' => 0xffeb, # left, right is ec
'superright' => 0xffec,
};
|
|
Finally here is the rest of the code that works for us know : sub special_keys () {
# see https://www.tcl.tk/man/tcl8.4/TkCmd/keysyms.html
# see https://www.ascii-code.com/fr
# see https://doc.ubuntu-fr.org/tutoriel/comprendre_la_configuration_du_clavier
# Liste des caractères mal encodés (ASCII vs UTF8) : °çéè৵ù || mal gérés par qemu (altgr)
return {
chr(233) => '2', # ord('é')=233 # é est mal encodé donc on prend le caractère 2 qui est sur la même touche
'~' => '2', # ~ est keysym no scancode in qemu donc on prend le caractère 2 qui est sur la même touche
'#' => '3', # '#' keysym = 35 : no scancode in qemu
'{' => '\'', # '{' keysym no scancode in qemu
'[' => '(', # '[' keysym no scancode in qemu
'|' => '-', # '|' keysym no scancode in qemu
'`' => '7', # ` keysym no scancode in qemu donc on prend le caractère 7 qui est sur la même touche
chr(232) => '7', # ord('è')=232 # è est mal encodé donc on prend le caractère 7 qui est sur la même touche
'\\' => '_', # '\' keysym no scancode in qemu
chr(231) => '9', # ord('ç')=231 # ç est mal encodé donc on prend le caractère 9 qui est sur la même touche
'^' => '9', # ^ est mal encodé donc on prend le caractère 9 qui est sur la même touche
chr(224) => '0', # ord('à')=224 # à est mal encodé donc on prend le caractère 0 qui est sur la même touche
'@' => '0', # @ keysym no scancode in qemu donc on prend le caractère 0 qui est sur la même touche
chr(176) => ')', # ord('°')=176 # '°' est mal encodé donc on le désigne par chr(176) et on prend le caractère ')' qui est sur la même touche
']' => ')', # ']' keysym no scancode in qemu
'}' => '=', # '}' keysym no scancode in qemu
chr(249) => '%', # ord('ù')=249 # ù est mal encodé donc on prend le caractère % qui est sur la même touche
chr(181) => '*', # ord('µ')=181 # µ est mal encodé donc on prend le caractère * qui est sur la même touche
chr(167) => '!', # ord('§')=167 # § est mal encodé donc on prend le caractère ! qui est sur la même touche
}
}
sub altgr_keys () {
# see http://en.wikipedia.org/wiki/IBM_PC_keyboard
# see https://www.tcl.tk/man/tcl8.4/TkCmd/keysyms.html
# see https://www.ascii-code.com/fr
# see https://doc.ubuntu-fr.org/tutoriel/comprendre_la_configuration_du_clavier
return {
'~' => chr(233), # é est mal encodé donc on le désigne par chr(233)
'#' => '"',
'{' => '\'',
'[' => '(',
'|' => '-',
'`' => chr(232), # è est mal encodé donc on le désigne par chr(232)
'\\' => '_',
'^' => chr(231), # ç est mal encodé donc on le désigne par chr(231)
'@' => chr(224), # à est mal encodé donc on le désigne par chr(224)
']' => ')',
'}' => '=',
#chr(164) => '$', # ¤ commenté car apparaît avec ê à la place... # ¤ est mal encodé donc on le désigne par chr(164)
#chr(183) => ':', # · semble non suporté ou accessible via une autre combinaison (shift+altgr+k) # · est mal encodé donc on le désigne par char(183)
chr(128) => 'e', # € est mal encodé donc on le désigne par char(128)
};
}
sub init_x11_keymap ($self) {
return if $self->keymap;
# create a deep copy - we want to reuse it in other instances
my %keymap = %$keymap_x11;
for my $key (30 .. 255) {
$keymap{chr($key)} ||= $key;
}
for my $key (1 .. 12) {
$keymap{"f$key"} = 0xffbd + $key;
}
for my $key ("a" .. "z") {
$keymap{$key} = ord($key);
bmwqemu::diag "[Keytab Shift Keys] $key : [$keymap{shift}, ".ord(uc $key)."]";
# shift-H looks strange, but that's how VNC works
$keymap{uc $key} = [$keymap{shift}, ord(uc $key)];
}
# VNC doesn't use the unshifted values, only prepends a shift key
for my $key (keys %{shift_keys()}) {
die_on_invalid_mapping($key) unless $keymap{$key};
bmwqemu::diag "[Keytab Shift Keys] $key : [$keymap{shift},$keymap{$key}]";
$keymap{$key} = [$keymap{shift}, $keymap{$key}];
}
my %altgrkeys=%{altgr_keys()};
for my $key (keys (%altgrkeys)) {
die_on_invalid_mapping($key) unless $keymap{$key};
bmwqemu::diag "[Keytab Altgr Keys] $key : [$keymap{altgr},$keymap{$altgrkeys{$key}}]";
$keymap{$key} = [$keymap{altgr}, $keymap{$altgrkeys{$key}}];
}
my %specialkeys=%{special_keys()};
for my $key (keys (%specialkeys)) {
die_on_invalid_mapping($key) unless $keymap{$key};
if (ref($keymap{$key}) eq 'ARRAY') {
if (ref($keymap{$specialkeys{$key}}) eq 'ARRAY') {
$keymap{$key}[-1] = $keymap{$specialkeys{$key}}[-1];
}
else {
$keymap{$key}[-1] = $keymap{$specialkeys{$key}};
}
bmwqemu::diag "[Keytab Special Keys] $key : @{$keymap{$key}}";
}
else {
if (ref($keymap{$specialkeys{$key}}) eq 'ARRAY') {
$keymap{$key} = $keymap{$specialkeys{$key}}[-1];
}
else {
$keymap{$key} = $keymap{$specialkeys{$key}};
}
bmwqemu::diag "[Keytab Special Keys] $key : $keymap{$key}";
}
}
$self->keymap(\%keymap);
foreach my $k (keys(%keymap)) {
bmwqemu::diag "[Keytab] Key=Char=$k Val=Keysym=$keymap{$k}";
}
}
sub replace_special_char {
my $chaine = shift;
#233 keysym du char é
my $needle=chr(233);
$chaine =~ s/é/${needle}/g;
#232 keysym du char è
$needle=chr(232);
$chaine =~ s/è/${needle}/g;
#231 keysym du char ç
$needle=chr(231);
$chaine =~ s/ç/${needle}/g;
#224 keysym du char à
$needle=chr(224);
$chaine =~ s/à/${needle}/g;
#176 keysym du char °
$needle=chr(176);
$chaine =~ s/°/${needle}/g;
#163 keysym du char £
$needle=chr(163);
$chaine =~ s/£/${needle}/g;
#249 keysym du char ù
$needle=chr(249);
$chaine =~ s/ù/${needle}/g;
#181 keysym char µ
$needle=chr(181);
$chaine =~ s/µ/${needle}/g;
#167 keysym du char §
$needle=chr(167);
$chaine =~ s/§/${needle}/g;
#128 keysym du char €
$needle=chr(128);
$chaine =~ s/€/${needle}/g;
return $chaine;
} |
Thanks - that's generally appreciated. Since you already have code to share it would make sense to create a PR then. Even if it isn't production-ready that helps because on a PR we can comment/discuss on code more easily (and see what has actually changed in your version). I suppose what you're writing makes sense but I haven't looked into that topic for a while (as it is not a priority for us) so I would have to have a closer look later to give you more feedback. |
|
Same as @Martchus , but broadly I think if we want to make any extensive changes here to try and fix this "properly", it is more or less a prerequisite to implement qemu's keycode extension to VNC. It is just too hard/weird/impossible to do this properly by sending keysyms over the wire. There are just too many levels of translation going on in that case. By implementing that extension we can send qemu physical scan codes instead of keysyms that it then translates to scan codes. Well, technically you're required to send both, but I think qemu ignores the keysym, it's just there to make the protocol happy. It reduces our problem to, more or less, "we know the character(s) we want to produce, and the layout our test has configured in the target system: what are the scan code(s) that represent the correct key(s) to produce the desired result?" |
|
If we do it that way, and I'm thinking this through right, I think all we really need is one big lookup table per layout supported, with some kinda handling of modified presses. The default would be for a US English layout, and we would map each typable character to the scancode or combination of scancodes required to produce that character on a US English keyboard. To support another layout, you just add a lookup table. It would be nice to make it easy to switch between them on demand in the test code, I guess, so you can implement tests where the SUT is using different layouts at different times (e.g. defaulting to US layout during boot, but you want to switch to French later). And there's a question just how sophisticated do we make it - do we handle compose keys? But I think it's a clearer and simpler design ultimately. |
|
I suppose that does beg the question "do we use the VNC console for anything that's not qemu? And if so, do those other things support qemu's extension?" |
Yes, we do. For instance the I don't think we need to support different keyboard mappings for all those backends, though. Of course we need to take care not to break any of those use cases (e.g. make additional mapping that might be QEMU-specific an opt-in). Note that there's also still the
I guess that needed to be looked up for each use of the VNC console specifically. I guess in general (and we probably want to keep the VNC console generic) the answer is no. |
|
ah, fun. that does make it less easy to do a really 'clean' approach :( i guess what we'd want to do is just always send keysyms that are appropriate for a US English layout, and send keycodes in the way discussed above for qemu, or something along those lines. it does seem like we'd wind up with lots of duplicate/parallel logic and lookup tables :( an alternative approach might be to subclass VNC.pm just for qemu, I guess, but that just sort of moves the complexity around a bit...ah, well. |
I created a PR right here : os-autoinst/os-autoinst#2457. The problem of this PR is that it removes the support of the en-us keyboard layout, so it can't be considered as is. |
If one selects a non US keyboard within the SUT, and then use
type_string()then for example one sees thatzandyare swapped when typing with a german keyboard selected.It seems that this is because keys are mapped to keycodes in
consoles/VNC.pmand this continues to assume a us layout, or perhaps the VM continues to apply a US keycode to layout mapping, or some such.I notice that one can tell the VM to use another layout by setting
KVMKB.One can see the problem in this screenshot, where the colour code it's trying to type is
#000000but as a result of selecting a British keyboard during the install, that comes out as£000000(which happens to work anyway :-) )Interestingly, if one sets
KVMKB=en-gbthat changes to~000000as seen here, which I assume to be becauseconsoles/VNC.pmincludes code that puts#inshift_keys, apparently declaring#to be a shifted3. On a UK keyboard however,#is not shifted, and is instead on the key adjacent to the lower part of the return key. If one shifts the#on a UK keyboard, one gets a~which I presume is where the~is coming from above.This would seem to depend upon the backend in use, so I've no idea if a similar issue exists for non-KVM backends, or if there are related but different issues.
If it's actually possible, it would be nice to be able to inform the SUT that one's selected a non-US mapping, so that when one says one is wanting to type e.g.
yor#, that each layer of this is sufficiently aware of the mapping to ensure that the same key gets to the SUT unchanged. Failing that, this problem and possible work-arounds should be documented somewhere, probably in thetype_string()docs.The text was updated successfully, but these errors were encountered: