Open nick-george opened 1 year ago
Is it possible to try with an en_US locale? I don't think we've really solved the capitalization issue, just put in enough work-arounds that it mostly works. I've always suspected locale as being the culprit but never had a good repo.
I don't know how often I have answered such questions in the past, but the VNC / RFB protocol is not ideal for being used with virtual machines. Daniel P. Berrangé is one of the QEMU core developers and has several related blog posts on this issue; read them if you're interested in the gory details.
The summary is this:
vncdotool
. The keyboard hardware sends a keycode like (2nd row, 2nd key from the left). The operating system on your PC translates this to 1
or !
or whatever is configured there.1
may have also been generated by the key from they numeric key block. This is the 2nd configuration, which can be specified by qemu -k …
and should match the keyboard layout of your client. (if multiple people with different layouts access the same VM, basically you have lost; actually not as you can re-configure QEMU on the fly.)vncdotool
you give it keysyms as arguments on the command line, e.g. 123
. So vncdotool
has to convert this into a sequence of key-presses, QEMU does its back-translation, and your OS inside the VM gets some keycodes.vncdotool
currently has no option to configure its keyboard layout (first conversion from above) and is hard-coded to en-US
: vncdotool/client.py.
There are other open issues related to that, e.g. #139 #209
Many thanks for your detailed response @pmhahn and @sibson. It's a lot to digest.
The discussion around it could be simplified to just vncdotool. If I use key shift-2
, I get a different result to using "type @". When I use type @
, I get a 2, but shift-2 works. This means that vncdotool is sending different keycodes for both scenarios. I want vncdotool to send the same data either way. The en_AU and en_US keyboard layouts are essentially the same (I'm not aware of any differences).
Can I easily troubleshoot how vncdotool converts from the user-supplied input to the virtual key-presses? Using the -v -v -v option, I can see it saying it's sending a '@', but from your explanation, it's actually sending raw key presses?
I understand that I could write a parser that tokenises each character of input I wish to send, then sets the appropriate shift-X
code to make it work (for US keyboards only), but it seems there must be a better way.
In the end, I've decided that I probably can't use this tool to do what I want to achieve (automatic configuration of a machine), as there are probably too many failure scenarios to account for (Window positions etc).
Feel free to close the ticket. It would be awesome if the content of your comment above was included in the main docs for the project.
Cheers, Nick
For an en-US
keyboard you're lucky and can use vncdo --force-caps …
: For the characters listed in
SPECIAL_KEYSUS = '~!@#$%^&*()+{}|:"<>?'
vncdo
will then automatically send shift-X
key presses and releases instead, which should work better with Qemu.
Can I easily troubleshoot how vncdotool converts from the user-supplied input to the virtual key-presses? Using the -v -v -v option, I can see it saying it's sending a '@', but from your explanation, it's actually sending raw key presses?
Just this week I observed a similar issue with a very old version of Qemu 2.6 from ~2016; I just opened https://github.com/sibson/vncdotool/pull/270 which includes a patch to improve logging the key-codes sent; feel free to give my branch a try.
Thanks @pmhahn for the great explanation. I suspect VM is one of the more common use cases these days, and it would make sense to implement the QEMU extension. Not sure what that means for other VMs, but anything that improves things so it just works for most people is a good thing.
Please include the following information:
vncdotool version: vncdotool==1.2.0 VNC server and version: QEMU VNC Server, version 6.2+dfsg-2ubuntu6.12 (ubuntu 22.04) Steps to reproduce
kvm -cdrom ~/Downloads/debian-12.1.0-amd64-netinst.iso -m 2048 -net nic -net user -vnc 127.0.0.1:2,password=off
vncdo -v -v -v -s localhost:2 type 'THISISaVncdotoolTest1234!@#$'
Expected result I'd expect to see the following text on the shellWhich erroneous result did you get instead
Additional information This is my locale, do you think it could be somehow involved?
I'm aware of the 'shift-' operations, but I was hoping not to have to write my own parser for every character sent. Looking through the issue history for this project, it seems the capitalisation issues were solved years ago, so I figure it's an issue with QEMU in particular? Have you got an suggestions on how I can fix?
Entering the same characters in a vnc viewer works fine.
Many thanks!