Bug 302951 - Ubuntu live CD does not support wacom tablet so mouse doesn't work
Summary: Ubuntu live CD does not support wacom tablet so mouse doesn't work
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: python-virtinst
Version: 8
Hardware: All
OS: Linux
low
low
Target Milestone: ---
Assignee: Xen Maintainance List
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-09-24 11:34 UTC by Richard W.M. Jones
Modified: 2007-11-30 22:12 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-10-04 17:02:01 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
/var/log/Xorg.0.log (27.60 KB, text/plain)
2007-09-25 09:29 UTC, Richard W.M. Jones
no flags Details
dmesg (14.17 KB, text/plain)
2007-09-26 10:59 UTC, Richard W.M. Jones
no flags Details

Description Richard W.M. Jones 2007-09-24 11:34:51 UTC
Description of problem:

The Ubuntu 7.04 live CD boots and runs fine under qemu, _except_
that the mouse does not work.  This makes it almost impossible to
run the hard disk installer and therefore to install Ubuntu as a
guest.

The problem turns out to be that ubuntu doesn't understand the wacom
graphics tablet which qemu now emulates.  It apparently detects it
but seems unable to initialize it.

Version-Release number of selected component (if applicable):

Ubuntu 7.04 (i386) Desktop version

xen-3.1.0-5rich2.fc8
kernel-xen-2.6.21-2940.fc8
libvirt-0.3.2-2.fc8
virt-manager-0.5.0-1.fc8

How reproducible:

Always.

Steps to Reproduce:
1. Download ubuntu live cd (http://ubuntu.com)
2. Install under QEMU
3.
  
Actual results:

Live CD boots OK but mouse pointer stays in the centre of the screen.

Expected results:

Able to move mouse pointer.

Additional info:

The precise error message (on Ubuntu) is:

# /etc/init.d/xserver-xorg-input-wacom restart
 * Doing Wacom setup...
cat: */id: No such file or directory

And the reason for this is that it is expecting some device
nodes to appear under /sys/bus/pnp/devices (but in fact this
directory is empty).

wacom.ko module is loaded.

I can't find any Ubuntu bug reports which seem to match this.

Comment 1 Daniel Berrangé 2007-09-24 21:39:48 UTC
Is there any way you can capture the /var/log/Xorg.0.log  logfile from the Live
CD ? Even when we enable the USB tablet, the PS/2 device should still be active,
so I'm puzzled why it can't get mouse events from that.

Oh, furthermore, we're not actally providing a Wacom tablet - we emulate a
EvTouch USB tablet, which is a generic USB HID device supported by the regular 
'evdev' driver in Xorg.

Comment 2 Richard W.M. Jones 2007-09-25 09:29:47 UTC
Created attachment 205041 [details]
/var/log/Xorg.0.log

Maybe I was confused by the Wacom message at boot.  In any case it's
easy for me to get any file from the live CD that you want because I've
got full network access.  Attached to this comment is /var/log/Xorg.0.log.

Comment 3 Daniel Berrangé 2007-09-25 21:49:05 UTC
So I have been able to reproduce the problem on FC6 guests too.

QEMU has multiple mouse drivers - PS/2, VMWare Mouse, and optionally USB Tablet
or USB Mouse. Latest virt-install automatically adds a USB tablet device to all
fullyvirt guests.

Now only one of these mouse drivers can see mouse events from the host at any
time. QEMU starts out with PS/2 getting events, and if either VMWare Mouse or
USB Tablet are activated then PS/2 stops getting events & the other appropriate
device gets them instead.

You can see this by using "Ctrl+Alt+2" to switch to the monitor & typing 'info
mice' - the "*" indicates the active device.

So what I think is happening is that Ubuntu is doing something - probing of some
form - which causes the USB Tablet device to activate, and thus all mouse events
get switched away from PS/2 to the USB Tablet. Unfortunately, the Ubuntu
xorg.conf is configured for /dev/input/mice, and the 'mouse' driver. The USB
Tablet does not appear to work in a way that results in events being fed into
/dev/input/mice, and so you get no cursor movement.

I'm puzzled on 2 accounts

 - What precise event causes the USB Tablet to be activated. The same thing
seems to happen on some versions of Fedora & RHEL too, but it doesn't on the
Fedora 7 live CD.
 - Why don't tablet events get fed into /dev/input/mice

I fear the only practical solution is going to be to only configure the USB
tablet on Windows guests by default, and not any Linux guests - at least until
distros switch to the new Xorg with hotplug automagic configuration of input
devices (Fedora 9 timescale).


Comment 4 Richard W.M. Jones 2007-09-26 10:59:01 UTC
Created attachment 206931 [details]
dmesg

The attachment is dmesg from the Ubuntu guest.

Is probing the USB tablet (as in the extract below) enough to
trigger QEMU to send it all events?

[   28.712753] usb 1-2: configuration #1 chosen from 1 choice
[   29.416007] usbcore: registered new interface driver hiddev
[   29.524119] input: QEMU 0.9.0 QEMU USB Tablet as /class/input/input2
[   29.524298] input: USB HID v0.01 Pointer [QEMU 0.9.0 QEMU USB Tablet] on
usb-
0000:00:01.2-2
[   29.524457] usbcore: registered new interface driver usbhid
[   29.524494] drivers/usb/input/hid-core.c: v2.6:USB HID core driver

Comment 5 Daniel Berrangé 2007-10-04 16:21:23 UTC
To make matters even worse, different versions of QEMU have differnet behaviour
wrt to mouse activation. I conclude there's no safe way to automatically enable
USB tablet for anything except Windows which knows how to automatically
configure it. So for non-Windows I'm going to make virt-install default to
PS2/mouse and have UI in virt-manager to let knowledgable people add a
USB/tablet post-install. When Xorg gains ability to auto-configure input devices
we can re-enable it by default on suitably new distros (Fedora 9 for example).


Comment 6 Daniel Berrangé 2007-10-04 17:02:01 UTC
Fix pushed to rawhie in python-virtinst-0.300.1-2.fc8

* Thu Oct  4 2007 Daniel P. Berrange <berrange> - 0.300.1-2.fc8
- Remove USB tablet for all except Windows (rhbz #302951)


Note You need to log in before you can comment on or make changes to this bug.