Keyboard problems with qemu when not using serial tty

[bwegh]

I have an issue with the keyboard when using the following qemu config with the image built by 'make image=cli':

It seems like some meta-key are always sent. eg when typing '1234567890' I get (already after I pressed the '1', the other keys seem to be ignored): /# ;1R when typing 'ls' I get the same after pressing the 'l'

when typing 'help' I once get and when pressing the 'l' the first line is removed: /# ;1R another time I get: /# ;1Rhelp and then everything works fine after deleting the text using backspace.

I also get strange typing when using the erlang image. Before sometimes CapsLock was set or not, right now I can't check due to the strange behaviour.

Everything works fine when using the ./scripts/run.py script.

\ qemu command * (QEMU emulator version 2.2.0) /usr/local/bin/qemu-system-x86_64 -enable-kvm \ -m 2G -cpu core2duo \ -smp 4 \ -device virtio-blk-pci,id=blk0,bootindex=0,drive=hd0,scsi=off \ -device virtio-rng-pci \ -drive id=hd0,if=none,file=${DISKIMG} \ -netdev user,id=un0 \ -device virtio-net-pci,netdev=un0 \ -rtc base=localtime,clock=host \ -no-quit -no-reboot

with DISKIMG pointing to the ./buil/release/usr.img.

[nyh]

I cannot reproduce this specific problem, but I do see a delay, and sometimes a hang, during startup until I press some key.

Probably the underlying reason for this bug is the code in the CLI which attempts to figure out the terminal's size. This code outputs an escape sequence ("Report Cursor Position") which makes the terminal send fake input which the program can read and includes information on where the cursor is (which can be used to get the terminal size). This output indeed ends with ";1R", so it is possible for some reason the code gave up on on reading the size, and only then it arrived. I don't know why - or why it doesn't happen on my machine.

I'll take a look at this code again again. @lightpriest are you getting these mails too?

[nyh]

I fixed a few bugs in the ps/2 keyboard driver (see the mailing list), but now things have actually become worse :-)

When I use run.py, cli.c sends the status report escape sequence, it gets two answers - one from the serial-port driver, and one from the VGA driver. And since it expects only one answer, it gets confused (and one of the answers gets printed as output, like you reported).

I'm not sure how to best solve this - our all "console multiplexor" thing is a real hack - if we do actually have two consoles, each can have different sizes, so indeed, what do expect to happen when we use this escape sequence?

[bwegh]

It works way better now directly on the VM, yet on the serial line (using scripts/run.py) I have now similar issues as before. The serial line moves the output to the beginning of the screen as on vga, yet the vm screen is not cleared. One can still read the message 'Booting from Hard Disk ....' and the end of the 'eth0: ' so the first line of the screen is something like: '/# 0: 10.0.2.15'

Wouldn't it be better to have the information about size etc at each end and move it from the multiplexer further towards the output/input part? Or as an easy solution right now support either the one or the other and make it a param for the loader?

[nyh]

On Thu, Dec 18, 2014 at 4:51 PM, Bas Wegh notifications@github.com wrote:

It works way better now directly on the VM, yet on the serial line (using scripts/run.py) I have now similar issues as before.

You've opened a pandora's box of bugs :-)

In the last couple of days sent three more patches to the mailing list, which haven't been committed yet (maybe if you can test them they will be committed more quickly). I hope these fix all the remaining bugs in this area.

I tried to explain in every patch what bug it fixes (there were several different bugs which sometimes aggravated each other, and sometimes cancelled each other!), but please let me know if something still doesn't make sense to you.

The serial line moves the output to the beginning of the screen as on vga,

yet the vm screen is not cleared. One can still read the message 'Booting from Hard Disk ....' and the end of the 'eth0: ' so the first line of the screen is something like: '/# 0: 10.0.2.15'

I'm not seeing this problem now (I do see the screen cleared before printing "eth0:..."), but if it exists, I think it's a separate issue.

Wouldn't it be better to have the information about size etc at each end and move it from the multiplexer further towards the output/input part?

The basic issue is that when you run with the serial port connected to a real user's terminal emulator (e.g., running qemu&osv inside an xterm window), OSv doesn't know this terminal's size! So what happens is that the OSv application (cli.c) prints an escape sequence known as ANSI DSR (\033[n), this is printed to the serial port and ends up sent to the xterm, which in turn (like any terminal emulator supporting the ANSI escape sequences) returns some "fake" input which qemu, and eventually OSv, can read, telling us the cursor position. This is how OSv's cli can figure out the size of the xterm it is running inside.

Or as an easy solution right now support either the one or the other and

make it a param for the loader?

Making the terminal size fixed (24x80) would have been a "good enough" solution for most cases.

We can indeed make the terminal rows and columns loader parameters (these parameters could set the tty's window size via TIOCSWINSZ), and pass this automatically from run.py. We can also pass $TERM this way from the host to the guest. This would be similar to the way that ssh (for example) passes the terminal type ($TERM) and size to the remote machine. The only problem is that it will rely on even more complexity in run.py - and if someone doesn't use run.py (like you didn't), it won't help him.

Nadav Har'El nyh@cloudius-systems.com

[nyh]

On Sun, Dec 21, 2014 at 1:08 AM, Nadav Har'El nyh@cloudius-systems.com wrote:

On Thu, Dec 18, 2014 at 4:51 PM, Bas Wegh notifications@github.com wrote:

It works way better now directly on the VM, yet on the serial line (using scripts/run.py) I have now similar issues as before.

You've opened a pandora's box of bugs :-)

In the last couple of days sent three more patches to the mailing list, which haven't been committed yet

Pekka has now committed these three additional patches. Can you please test if the problems you've been seeing are fixed in the latest master?

Thanks, Nadav.

[bwegh]

Hello Nadav,

At the moment I do not have as much time as I would like to have for contributing to OSv.

I ran a short test and it works great for me now except clearing the screen. One last patch is on the the mailing list to completely clear the sreen.

Thanks for the fixes and the fast help, Bas