Affected BSP: qemuppc Affected image: core-image-sato-sdk Affected build: 1.7.rc3: 5367855fe56db0c09b8fa7bb423b9de18d11eecc AB link: http://autobuilder.yoctoproject.org/pub/releases/yocto-1.7.rc3/machines/qemu/qemuppc/core-image-sato-sdk-qemuppc.ext Steps to reproduce: 1. Download ext3 & kernel files from AB 2. Source an environment 3. runqemu qemuppc core-image-sato-sdk Expected behaviour: Mouse and keyboard input should be recognised by qemu. Observed behaviour: Mouse input does not register in qemu window
Reproducible also on qemux86-64.
Does this happen every boot or just sometimes? or only with particular images?
Actually, mouse clicks don't work, or maybe the interface is non-functional, mouse pointer is present and functional. Bug is not erratic, is 100% reproducible in my books. Like I said, it's also reproducible on qemux86-64 machine.
Reverting the kernel used by qemux86-64 to linux 3.14.19 solves the issue.
I suspect there are 2 different issues here. For qemuppc, the cursor is not present and no input registers. While checking for other images affected I encountered a different issue for qemumips, similar to what Cristian describes. Cursor is present and clicks register, however the cursor position does not correspond to the place the clicks are registered. Basically, I'd have to click about 1cm to the left and about 1/2 of a cm above the button I wanted to affect. I hope this description helps you visualise the issue at hand. Mihail
Additional testing done. Mouse cursor location is bad on all qemu machines, except qemuppc, where it is not present at all. Tests were done on core-image-sato-sdk images. Also tested core-image-sato for qemumips, problem is present as well.
Investigation started.
The most probable root cause is the lack of USB Wacom touchscreen driver from the 3.17 kernel config. USB Wacom driver has been renamed, and CONFIG_TABLET_USB_WACOM is no longer a valid kernel config option. Working on replacing with a valid option, that will restore touchscreen capability to qemu VMs (as is the case for qemux86-64 machine).
Partial fix has been sent for review, work will continue on qemuppc as the issue is not solved in there.
*** Bug 6811 has been marked as a duplicate of this bug. ***
I see exactly the same behaviour on all qemu machines. The clicks go through, but they are dropped, or are offset. Is there some sort of missing calibration with the new hid driver ?
Yes. As I understand it, the virtual tablet in qemu needs to report calibration data to the guest.
QEMU BSPs are using Linux kernel 3.14.x for the moment, so the issue is no longer present. This issue needs to be re-tested and fixed is needed after QEMU machines will switch to a newer Linux kernel.
Not sure about the status of this - it sounds like it's waiting for the qemu machines to move to 3.17, but the 3.17 move is waiting on this... In any case this is also blocking yocto-bsp 3.17 updates, which are needed for master and dizzy.
Just to clarify, this bug will block the 1.7.1 point release, which from today's tech meeting, will occur just after 1.8 M1. So it would seem that the target of 1.8 M4 needs adjusting.
The old driver was TABLET_USB_WACOM, which was moved to: +config HID_USB_WACOM + tristate "Wacom Intuos/Graphire tablet support (USB)" + depends on HID + select POWER_SUPPLY + select NEW_LEDS + select LEDS_CLASS + help + Say Y here if you want to use the USB version of the Wacom Intuos + or Graphire tablet. However, simply changing the config option doesn't help - the problem still exists with the new driver enabled. The patches that moved it to the HID subsystem made a lot of changes, and the trouble with it started after the following patch: commit 29b4739134c73a2873adec93346f09bb76d6a794 Author: Benjamin Tissoires <benjamin.tissoires@redhat.com> Date: Thu Jul 24 12:52:23 2014 -0700 Input: wacom - switch from an USB driver to a HID driver i.e. reverting the wacom patches in that patchset, including that one, we get a functional mouse again with no problems.
Why does this block 1.7.1? 1.7.x is still using kernel 3.14. As far as I'm aware this bug (which should be re-titled, I'll do that now) only impacts master as its an interaction between qemu and linux 3.17.
Well, 1.7 was supposed to be 3.17, but this bug blocked it from happening for the release. And in turn, the 1.7 yocto-bsp updates were blocked from going into 1.7 because 1.7 wasn't at 3.17, even though there's no real dependency of the yocto-bsp updates on what the 1.7 release itself selects as the default kernel version - the BSPs generated by yocto-bsp default to 3.17 and work just fine in either case. It was seen as rather untoward to have yocto-bsp defaulting to 3.17 while the release was at 3.14, and the plan was to fix that in the point release. So my interest is to get the point release to 3.17 so that all my yocto-bsp work isn't wasted. And really, there's no reason we should be releasing two yocto releases in a row with the same kernel anyway.
I must be confused. Poky 1.7 shipped with the 3.14 kernel used by default in the qemu machines, and the 3.17 kernel as an option. Any patches to anything in poky can be merged into master and *important* fixes backported to the 1.7 branch. This bug relates to how qemu images booted with kernel 3.17 don't have working input. Fixing this needs to happen - and we're in discussion with the qemu maintainers about the best way forward - but patching the kernel and qemu, and then changing the default kernel isn't suitable for a point release. Other patches, such as unrelated fixes to the kernel and yocto-bsp, may well be suitable for a point release and they can be considered independently.
When I posted the yocto-bsp udpates for 1.7, RP asked if we could wait until the point release to get them in. The assumption being that the point release would be moving to 1.7. Of course there's no way to fix the kernel problem without kernel patches. I didn't realize it also meant patches to qemu, but whatever, if we can't pull in kernel or qemu patches into point releases, I'll just have to change my plans for yocto-bsp updates in the future i.e. to start working on them only after poky has pulled in the patches moving the qemu and core machines to a new kernel. In the past, when we did that, it meant delaying the release (IIRC the 1.6 release was delayed for that and other reasons). As it turns out, getting a head start carries its own risks, in this case a lot of wasted work and testing.
Just to be clear the only thing that I'll argue against merging into 1.7.1 is changing the default kernel for qemu* to 3.17, as that's too invasive for a point release. Backing up I'm not sure why yocto-bsp bugs are blocking on this, why would the kernel used by qemu have an impact on the yocto-bsp tool?
The yocto-bsp bugs blocking on this are built on or will be built on top of the yocto-bsp updates, and I don't plan on reworking them for a pre-yocto-bsp-updates state. So if the yocto-bsp updates can't go in, then either can the bugs on top of them. Again, the kernel used by the poky qemu machines really has nothing technically to do with this - it's just that we can't have a situation where yocto-bsp generates BSPs with 3.17 kernels when the main release doesn't do so.
OK, so I won't bother worrying about this for 1.7.1 any more. So I've just resubmitted the yocto-bsp updates for master, which shouldn't have the same restrictions on pulling it in since this bug will be fixed by the 1.8 release (by then the kernel will be at 3.20 or so and I'll have to redo the yocto-bsp updates, but that's beside the point).
Problem with wacom in qemu resolved with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ef7ea3869ce34b59df146d74e9c7c96ae8a2de2a
Verified on master: 22c38e2d8a058619e3d05534b5e830b750aa4241