Fix had been included here:
http://git.qemu.org/?p=qemu.git;a=commitdiff;h=df00bed0fa30a6f5712
... so closing this bug ticket now.
** Changed in: qemu
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed
no I don't believe it was your fault
I couldn't get the code compile even without your patch...
man this sucks... i had hoped it would be upstream with 0.15 but I might
have to try to compile it by myself again
thanks ;)
--
You received this bug notification because you are a member of qemu-
Alright, I've sent a patch to qemu-devel. Let's see what happens now...
--
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:
a it worked, just tried it with latest stable 0.15 git !!! finally
you are my hero! =)
--
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:
for which version is the last patch?
also 12.3?
--
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
Pretty sure it was the latest Arch package: 0.14.1. Did you have
trouble applying it?
I can run back and make a patch against git if you can't use this.
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
This is probably the source of the problem. As you say it'd be best to
use chtype directly if it can be done cleanly, unfortunately it looks
like it'll add a curses specific snippet in console.h, but so be it.
The only other option is to add a conversion step in curses.c and give
up zero-copy
How about using CONFIG_CURSES? If we --enable-curses, then we know we
have curses.h and chtype. If we --disable-curses, then we don't care.
Patch attached. It's a no-op if curses is disabled, and it fixes the
issue on my machine with curses enabled. I had to undef the color
constants from
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;
If I remember correctly, the type is unsigned long because it needs to
match chtype as declared in curses.h. On some implementations of
curses it may be declared differently, we really should use the chtype
type directly but console.h is also used when the use of curses was
disabled in qemu
any news on that bug?
--
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:
I just compiled from git and the problem persists.
I will reiterate that the issue appears to be with the word size of the
types used, not with endianness; see comment 4. I have not dug any
further into the QEMU code to see if I find a more correct-looking
solution than the quick patch I have
Hi Devin,
Can you test if this bug still exists with 0.14 (or better still, a git
build)?
Brad
--
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:
This patch should address the problem. I've submitted it to qemu-devel.
** Patch added: 0001-Fix-console_write_ch-on-64-bit-big-endian-hosts.patch
http://launchpadlibrarian.net/49569832/0001-Fix-console_write_ch-on-64-bit-big-endian-hosts.patch
** Changed in: qemu
Status: New = In
14 matches
Mail list logo
