Perhaps you have found an endianness bug as well, but my issue is with word size (my host is a 64-bit Intel). I manually applied the patch to a 0.12.3 build, and I am still seeing the problem with the curses console.
It seems that the console_ch_t type is used in a number of different contexts. The console.c and console.h files use console_ch_t fairly uniformly. However, the `screen' array in curses.c is cast to both uint8_t* and chtype* (unsigned int* according to my curses library) and passed as console_ch_t* (unsigned long*) to vga_hw_text_update. That's three different bit-sizes on my machine... is it possible that the problem lies here? -- x86_64 host curses interface: spacing/garbling https://bugs.launchpad.net/bugs/568614 You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. Status in QEMU: In Progress Bug description: Environment: Arch Linux x86_64, kernel 2.6.33, qemu 0.12.3 Steps to reproduce: 1. Have a host system running 64-bit Linux. 2. Start a qemu VM with the -curses flag. Expected results: Text displayed looks as it would on a real text-mode display, and VM is therefore usable. Actual results: Text displayed contains an extra space between characters, causing text to flow off the right and bottom sides of the screen. This makes the curses interface unintelligible. The attached patch fixes this problem on 0.12.3 on my installation without changing behavior on a 32-bit machine. I don't know enough of the semantics of console_ch_t to know if this is the "correct" fix or if there should be, say, an extra cast somewhere instead.
