Public bug reported:
I *believe* (not confirmed) that the old standard PC serial ports, when
configured with a character size of 7 bits or less, should set non-data
bits to 0 when the CPU reads received chars from the read register.
qemu doesn't do this.
Windows 1.01 will not make use of a serial mouse when bit 7 is 1. The
ID byte that the mouse sends on reset is ignored. I added a temporary
hack to set bit 7 to 0 on all incoming bytes, and this convinced windows
1.01 to use the mouse.
note 1: This was using a real serial mouse through a passed-through
serial port. The emulated msmouse doesn't work for other reasons.
note 2: The USB serial port I am passing through to the guest sets non-
data bits to 1. Not sure if this is the USB hardware or linux.
note 3: I also needed to add an -icount line to slow down the guest
CPU, so that certain cpu-sensitive timing code in the guest didn't give
up too quickly.
** Affects: qemu
Importance: Undecided
Status: New
** Tags: serial
--
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/1891829
Title:
High bits(s) sometimes set high on rcvd serial bytes when char size <
8 bits
Status in QEMU:
New
Bug description:
I *believe* (not confirmed) that the old standard PC serial ports,
when configured with a character size of 7 bits or less, should set
non-data bits to 0 when the CPU reads received chars from the read
register. qemu doesn't do this.
Windows 1.01 will not make use of a serial mouse when bit 7 is 1. The
ID byte that the mouse sends on reset is ignored. I added a temporary
hack to set bit 7 to 0 on all incoming bytes, and this convinced
windows 1.01 to use the mouse.
note 1: This was using a real serial mouse through a passed-through
serial port. The emulated msmouse doesn't work for other reasons.
note 2: The USB serial port I am passing through to the guest sets
non-data bits to 1. Not sure if this is the USB hardware or linux.
note 3: I also needed to add an -icount line to slow down the guest
CPU, so that certain cpu-sensitive timing code in the guest didn't
give up too quickly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/1891829/+subscriptions
