I just checked out the ncurses source - it looks like the type of "chtype" actually depends on how ncurses is configured at build time:
curses.h.in: #if @cf_cv_enable_lp64@ && defined(_LP64) typedef unsigned chtype; typedef unsigned mmask_t; #else typedef unsigned @cf_cv_typeof_chtype@ chtype; typedef unsigned @cf_cv_typeof_mmask_t@ mmask_t; #endif So even if Qemu targets only ncurses, we can't assume that chtype is anything in particular. In light of that, I guess this bug boils down to "let's use chtype directly," which (naively) seems like it could be #ifdef'd pretty easily. -- You received this bug notification because you are a member of qemu- devel-ml, which is subscribed to QEMU. https://bugs.launchpad.net/bugs/568614 Title: x86_64 host curses interface: spacing/garbling 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. To manage notifications about this bug go to: https://bugs.launchpad.net/qemu/+bug/568614/+subscriptions
