Hi, > With this patch, the gtk and sdl UIs are working fine.
Good. > Under the vnc UI, > a lot of keys don't work, unless the option -k is used. According to the > manpage, this options is needed for the vnc UI: > > -k language > Use keyboard layout language (for example "fr" for French). > This option is only needed where it is not easy to get raw PC keycodes > (e.g. on Macs, with some X11 servers or with a VNC display). You don't > normally need to use it on PC/Linux or PC/Windows hosts. Which vnc client is this? Tried remote-viewer? > However, using -k pt-br, the numpad period key generates a comma and not > a period (without -k pt-br, it also generates a comma). I think that > your patch does not cover the vnc UI, as it requires the option -k, > which is controlled by the file /usr/share/qemu/keymaps/pt-br. Well, I think this is a pretty fundamental and unfixable issue: In case the vnc client does *not* support the extension to send raw keycodes qemu tries to figure the raw keycode using the symbol (i.e. '.') it got from the vnc client and the keymap configured (/usr/share/qemu/keymaps/pt-br in your case). In case there are two keys generating the same symbol it is impossible to figure which of the two keys was actually pressed. And exactly that is the case here: There are two keys generating '.': The one on the numpad and the other one outside the numpad. [ adding debian bug back to Cc: to make this visible for others ] > A question: why do you call key 129 as KP_COMMA in the comment? Wouldn't > KP_period be more adequate? Using the linux input layer naming (see /usr/include/linux/input.h). cheers, Gerd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
