6810 2014-10-07 08:22:42 +0000 Qemu virtual wacom doesn't work with Linux 3.17 2015-02-06 10:10:05 +0000 1 1 7 Build System, Metadata & Runtime BSPs bsps-runtime 1.7 x86 ppc VERIFIED FIXED High major 1.8 M4 1 stanciux.mihail cristian.iorga alexandru.c.georgescu bruce.ashfield cristian.iorga ionutx.chisanovici richard.purdie ross.burton tom.zanussi yp.kernel.watcher yp.watcher stanciux.mihail --- Regression (Used to work) No (bug/feature does not impact docs) oldest_to_newest 46154 0 stanciux.mihail 2014-10-07 08:22:42 +0000 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 46155 1 cristian.iorga 2014-10-07 09:05:13 +0000 Reproducible also on qemux86-64. 46158 2 richard.purdie 2014-10-07 09:38:14 +0000 Does this happen every boot or just sometimes? or only with particular images? 46161 3 cristian.iorga 2014-10-07 11:19:47 +0000 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. 46162 4 cristian.iorga 2014-10-07 11:20:31 +0000 Reverting the kernel used by qemux86-64 to linux 3.14.19 solves the issue. 46165 5 stanciux.mihail 2014-10-07 12:14:29 +0000 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 46167 6 stanciux.mihail 2014-10-07 12:56:43 +0000 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. 46172 7 cristian.iorga 2014-10-07 14:28:34 +0000 Investigation started. 46173 8 cristian.iorga 2014-10-07 14:33:01 +0000 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). 46180 9 cristian.iorga 2014-10-07 21:33:33 +0000 Partial fix has been sent for review, work will continue on qemuppc as the issue is not solved in there. 46246 10 cristian.iorga 2014-10-09 15:24:26 +0000 *** Bug 6811 has been marked as a duplicate of this bug. *** 46326 11 bruce.ashfield 2014-10-14 17:47:55 +0000 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 ? 46327 12 ross.burton 2014-10-14 18:57:15 +0000 Yes. As I understand it, the virtual tablet in qemu needs to report calibration data to the guest. 46711 13 cristian.iorga 2014-10-31 16:27:10 +0000 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. 47218 14 tom.zanussi 2014-11-26 19:31:53 +0000 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. 47297 15 tom.zanussi 2014-12-02 18:51:51 +0000 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. 47298 16 tom.zanussi 2014-12-02 19:00:15 +0000 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. 47299 17 ross.burton 2014-12-02 19:50:46 +0000 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. 47300 18 tom.zanussi 2014-12-02 20:02:00 +0000 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. 47301 19 ross.burton 2014-12-02 20:16:04 +0000 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. 47302 20 tom.zanussi 2014-12-02 20:29:01 +0000 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. 47303 21 ross.burton 2014-12-02 20:52:05 +0000 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? 47304 22 tom.zanussi 2014-12-02 20:59:02 +0000 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. 47337 23 tom.zanussi 2014-12-03 17:27:03 +0000 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). 47441 24 richard.purdie 2014-12-08 21:14:33 +0000 Problem with wacom in qemu resolved with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ef7ea3869ce34b59df146d74e9c7c96ae8a2de2a 48603 25 stanciux.mihail 2015-02-06 10:10:05 +0000 Verified on master: 22c38e2d8a058619e3d05534b5e830b750aa4241