Missing letters in spice client session with KVM guest

Description of problem:
There are missing letters in various screens of anaconda in the Fedora 19 TC3 build. See the attached screenshots.

Version-Release number of selected component (if applicable):
Fedora 19 TC3
anaconda 19.30.5-1

How reproducible:
every time

Steps to Reproduce:
1. Use the netinst ISO image to build a virtual machine:
  virt-install --name=test-machine101 --ram=1024 --vcpus=2 \
    --graphics=spice --noautoconsole \
    --os-type=linux --os-variant=fedora18 \
    --network=network=default,model=virtio \
    --cdrom=/var/lib/libvirt/images/Fedora-19-TC3-x86_64-netinst.iso \
    --disk=/var/lib/libvirt/images/test-machine101.img,bus=virtio,size=10
2. Navigate the anaconda hub and spokes

Actual results:
letters are missing, e.g., in the Software Selection spoke, the GNOME Desktop group description is
  " NOME is a highly intuitive..."
where did the G in GNOME go?

and in the Installation Source spoke, the ISO file Verify button is " erify" and the Updates section is " pdates"

Expected results:
all the letters in the words are visible

Additional info:

Created attachment 760799
hub screenshot

Under Software Selection, the "D" is missing in "Cinnamon esktop"

Created attachment 760800
installation source spoke screenshot

1. The ISO file Verify button is missing the "V"
2. The Device name is " irtio Block Device (5 MB "
3. Updates is " pdates"
4. in Additional repositories, the Proxy URL field is "Pro y RL:"
5. the checkbox above it says "This RL efers to a mirror list"
6. Usename field is " sername:"

Created attachment 760802
software selection spoke screenshot

I'm not even sure what the column titles are; they read
  " a e E e"
and
  "A -O Se e e E e "

what???

there are more errors on the screens such as "Books and uides" and " NOME 2"

It's probably all the characters that are underlined to denote that they're the character to use for alt+(character) keyboard combinations? Or something like that?

This seems bad enough to call a blocker, though I don't know what criterion I'd go for immediately.

Created attachment 760803
disks spoke screenshot

Select the device(s) yo 'd li e to install to. They ill e left nto ched ntil yo clic on the main men 's Be in Installation tton.

This might be a virt problem with spice. I tried again with VNC and I cannot reproduce the problem.

  virt-install --name=test-machine101 --ram=1024 --vcpus=2 \
    --graphics=vnc ...

I've tested a few more times with VNC vs Spice and it only happens with Spice, so I'm moving this to virt-manager (but I suppose it could be xorg-x11-drv-qxl or some other virt component). I guess this might not be a blocker after all?

CCing Ajax and airlied for the xorg-x11-drv-qxl angle. I'll see if I can reproduce this here with Spice/qxl.

FWIW I can't reproduce this with my usual test VM (which I've been using for many releases, so its xml definition is relatively old). On an F19 host, with the guest using Spice/qxl, booting F19 Final TC3 netinst ISO and going to the Software Selection spoke, I don't see any problems. All characters render fine.

Created attachment 761390
missing letters from Live image

I tried today on different host, also running Fedora 19 with latest packages, and I used Fedora-Live-Desktop-x86_64-19-TC3-1.iso live image and I'm experiencing missing letters here too as seen in the attached screenshot.

This may be unrelated, but I'm also seeing a bug with the mouse cursor registering clicks a few pixels to the left of the actual cursor when using Spice graphics. This makes it difficult to scroll with the narrow scroll bars from the Adwaita theme. See bug 974662

Confirmed and this is not limited to Anaconda but running live as well.

+1 blocker

I'm still not seeing it, so there's clearly *some* config issue of some kind here. Are you guys actually using the qxl driver?

Stock default being used with virt on F18
( virt-manager-0.10.0-0.5.gitde1695b2.fc18.noarch )

Which has...

Video
Model: QXL
RAM: 64 MB
Heads: 1

Are you guys booting 64-bit or 32-bit images?

I live on the 21 century so I use 64bit...

I'm using all 64-bit, both host and guest. And I'm seeing it on two different systems.

I currently have installed on one host, my laptop:

~]$ rpm -qa | egrep -i 'virt|qemu|spice|qxl' | sort
ipxe-roms-qemu-20130517-2.gitc4bce43.fc19.noarch
libgovirt-0.1.0-1.fc19.x86_64
libvirt-1.0.5.2-1.fc19.x86_64
libvirt-client-1.0.5.2-1.fc19.x86_64
libvirt-daemon-1.0.5.2-1.fc19.x86_64
libvirt-daemon-config-network-1.0.5.2-1.fc19.x86_64
libvirt-daemon-config-nwfilter-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-interface-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-libxl-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-lxc-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-network-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-nodedev-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-nwfilter-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-qemu-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-secret-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-storage-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-uml-1.0.5.2-1.fc19.x86_64
libvirt-daemon-driver-xen-1.0.5.2-1.fc19.x86_64
libvirt-daemon-kvm-1.0.5.2-1.fc19.x86_64
libvirt-daemon-qemu-1.0.5.2-1.fc19.x86_64
libvirt-gconfig-0.1.6-1.fc19.x86_64
libvirt-glib-0.1.6-1.fc19.x86_64
libvirt-gobject-0.1.6-1.fc19.x86_64
libvirt-python-1.0.5.2-1.fc19.x86_64
perl-Sys-Virt-1.0.5-1.fc19.x86_64
qemu-1.4.2-3.fc19.x86_64
qemu-common-1.4.2-3.fc19.x86_64
qemu-guest-agent-1.4.2-3.fc19.x86_64
qemu-img-1.4.2-3.fc19.x86_64
qemu-kvm-1.4.2-3.fc19.x86_64
qemu-kvm-tools-1.4.2-3.fc19.x86_64
qemu-system-alpha-1.4.2-3.fc19.x86_64
qemu-system-arm-1.4.2-3.fc19.x86_64
qemu-system-cris-1.4.2-3.fc19.x86_64
qemu-system-lm32-1.4.2-3.fc19.x86_64
qemu-system-m68k-1.4.2-3.fc19.x86_64
qemu-system-microblaze-1.4.2-3.fc19.x86_64
qemu-system-mips-1.4.2-3.fc19.x86_64
qemu-system-or32-1.4.2-3.fc19.x86_64
qemu-system-ppc-1.4.2-3.fc19.x86_64
qemu-system-s390x-1.4.2-3.fc19.x86_64
qemu-system-sh4-1.4.2-3.fc19.x86_64
qemu-system-sparc-1.4.2-3.fc19.x86_64
qemu-system-unicore32-1.4.2-3.fc19.x86_64
qemu-system-x86-1.4.2-3.fc19.x86_64
qemu-system-xtensa-1.4.2-3.fc19.x86_64
qemu-user-1.4.2-3.fc19.x86_64
redland-virtuoso-1.0.16-2.fc19.x86_64
spice-glib-0.19-1.fc19.x86_64
spice-gtk-0.19-1.fc19.x86_64
spice-gtk3-0.19-1.fc19.x86_64
spice-gtk-python-0.19-1.fc19.x86_64
spice-server-0.12.3-1.fc19.x86_64
spice-vdagent-0.14.0-2.fc19.x86_64
virt-dmesg-0.3.0-8.fc19.x86_64
virt-install-0.10.0-0.5.gitde1695b2.fc19.noarch
virt-manager-0.10.0-0.5.gitde1695b2.fc19.noarch
virt-manager-common-0.10.0-0.5.gitde1695b2.fc19.noarch
virt-top-1.0.8-4.fc19.x86_64
virtuoso-opensource-6.1.6-3.fc19.x86_64
virt-v2v-0.9.0-2.fc19.x86_64
virt-viewer-0.5.6-1.fc19.x86_64
virt-what-1.12-3.fc19.x86_64
virt-who-0.8-7.fc19.noarch
xorg-x11-drv-qxl-0.1.1-0.8.20130514git77a1594.fc19.x86_64

And, as mentioned above, I create the VM with:

virt-install --name=f19tc3 --ram=1024 --vcpus=2 \
    --graphics=spice --noautoconsole \
    --os-type=linux --os-variant=fedora18 \
    --network=network=default,model=virtio \
    --cdrom=/var/lib/libvirt/images/Fedora-19-TC3-x86_64-netinst.iso \
    --disk=/var/lib/libvirt/images/f19tc3.img,size=10,bus=virtio

which creates this:

~]$ virsh dumpxml f19tc3
<domain type='kvm' id='7'>
  <name>f19tc3</name>
 ...

And the /tmp/X.log from the Anaconda environment confirms it's using QXL graphics:

[ 14.026] (==) Matched qxl as autoconfigured driver 0
[ 14.026] (==) Matched qxl as autoconfigured driver 1
[ 14.026] (==) Matched vesa as autoconfigured driver 2
[ 14.026] (==) Matched modesetting as autoconfigured driver 3
[ 14.026] (==) Matched fbdev as autoconfigured driver 4
[ 14.026] (==) Assigned the driver to the xf86ConfigLayout
[ 14.026] (II) LoadModule: "qxl"
[ 14.026] (II) Loading /usr/lib64/xorg/modules/drivers/qxl_drv.so
[ 14.098] (II) Module qxl: vendor="X.Org Foundation"
[ 14.098] compiled for 1.14.1, module version = 0.0.0
[ 14.098] Module class: X.Org Video Driver
[ 14.098] ABI class: X.Org Video Driver, version 14.1

I also noticed this in my X.log:

[ 14.230] qxl_kms_surface_create: Bad bpp: 1 (1)
[ 14.231] qxl_kms_surface_create: Bad bpp: 1 (1)
[ 14.231] qxl_kms_surface_create: Bad bpp: 1 (1)

This error comes from a recent commit to the qxl driver:
  qxl: add KMS support v1.2
http://cgit.freedesktop.org/xorg/driver/xf86-video-qxl/commit/?id=3e37b2c

So, with that clue, I restarted my virtual machine and added "nomodeset" to the kernel command line options, and I'm not seeing any missing letters! The graphics all look fine.

It's also curious that it's only text that's missing: all other widgets -- scroll bars, radio buttons, check boxes, etc -- look just fine.

Furthermore, I opened another bug last week about the mouse cursor registering clicks a few pixels away from the actual pointer when using Spice/QXL; see bug 974662. This bug is also fixed when using nomodeset!

Re-assigning to qxl so relevant folks can weigh in.

*** Bug 974040 has been marked as a duplicate of this bug. ***

Discussed at 2013-06-17 blocker review meeting: http://meetbot.fedoraproject.org/fedora-blocker-review/2013-06-17/f19final-blocker-review-6.2013-06-17-16.01.log.txt . Accepted as a blocker per criteria "The installer must be able to complete an installation using all supported interfaces" and "The release must be able host virtual guest instances of the same release." - if you're affected by this bug, installation becomes a game of chance unless you already know the installation interface intimately.

We reserve the right to change the decision if further data suggests it's less severe or widespread than we thought. X devs, we'd really appreciate your input on what may be causing this, and why some people see it (Jeff, Lukas, Jan, Johann) but others don't (me, Kamil). All testers seem to be testing x86_64 images on x86_64 hosts using qxl/SPICE graphics.

xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19

Note that this fix just missed TC5, but should make the next build. I could throw together a live image with the fix in it tomorrow, perhaps.

Just wanted to note this is a workaround, since the fix is disabling composite support.

Is it enough to fix this for F19 or do we need to fix this in F18 as well?

I updated to xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19 in my VM and it seems to be working well so far.

Package xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-11150/xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19
then log in and leave karma (feedback).

we don't have KMS support in f18 so if you see it there its a different bug,

and yes its a workaround, but composite support makes no sense with gnome-shell running anyways, and I think composite support in UMS mode needs a lot more work as well.

Jeff, could you add positive karma to the update?

Per Jeff's confirmation in c#27, setting VERIFIED.

xorg-x11-drv-qxl-0.1.1-0.9.20130514git77a1594.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.