6862 2014-10-21 18:41:08 +0000 input subsystem testing 2025-07-03 14:47:39 +0000 1 1 10 QA/Testing Runtime Testing general unspecified x86 Multiple NEW Medium enhancement Future 10604 1 dvhart unassigned alexandru.c.georgescu benjamin.esquivel bluelightning randy.macleod ross.burton sgw --- --- No (bug/feature does not impact docs) oldest_to_newest 46480 0 dvhart 2014-10-21 18:41:08 +0000 In order to identify issues with input, specifically keyboard, mouse, and touchpad/screen, we should consider adding some QA testing surrounding the Linux input and Xorg input drivers. These should include usability testing on both QEMU and yocto-bsp reference BSPs. Tests need to be identified and possible written. Automation should be considered wherever possible. 46541 1 ross.burton 2014-10-23 14:56:06 +0000 Keyboard is relatively simple: inject key events in the X11 that is running qemu, and run a tool in the guest that knows what keys to expect. Mouse is trickier: again inject mouse motion and clicks and see what the tool in the guest receives. The catch here being that we'd need to map from "I want to click at 100x100 in the guest" to the correct location in the X display (taking into account qemu location, window decoration size, etc). 49688 2 ross.burton 2015-03-24 11:58:12 +0000 Yeah I didn't get any time to actually do this. Moving to 1.9M2. 60015 3 ross.burton 2016-03-16 14:04:01 +0000 Thinking about this a bit more, the problems we've been having can't be automated trivially as they're dependent on the qemu input device. Lets start by ensuring that the manual test cases would catch all the input problems. 63589 4 benjamin.esquivel 2016-07-01 16:46:25 +0000 In the device automation that is work in progress there are Human Interface Device emulators that can automate keyboard/mouse(no touchpad though) inputs to a device under test. having automated control of the HIDs and also controlling the application that runs on the device completes the loop for making this fully automated. If I am understanding correctly this ticket, a test case for this matter would input keyboard keystrokes and/or mouse movement/clicks and you would expect to see the entire sequence validated at the DUT. Please confirm. If my assumptions are correct, we have a dependency on the device automation items which are targeted for the 2.2 M3 and release validation. That would make it a stretch to finalize a test case like this for that same time. But 2.3 M1 seems very feasible. One other thing is that if this has been an area where a considerable number of issues have arisen then it could be considered having manual testing for this upcoming release, while the automated testing happens. Please advise. 63956 5 ross.burton 2016-07-13 23:40:34 +0000 So the background to this was that there were some kernel updates that had a bit of testing on real hardware and passed the AB, and nobody noticed until the next milestone that input under qemu was *entirely* broken. Thus, the desire for automated testing which can be done on the autobuilder. I admit that this goal isn't simple, and may not be feasible in a way that is actually useful. The first step should be to ensure that the manual testing covers all cases: check that all mouse buttons are working, keyboard works fine, etc in both real hardware and qemu. Subsequently performing remote control of real hardware would be good. Rescheduling to 2.3 makes perfect sense to me given the scope of this. 63996 6 benjamin.esquivel 2016-07-14 19:18:02 +0000 Ack. 68688 7 benjamin.esquivel 2016-11-29 17:27:10 +0000 depending on bug 10604, which is targeted for 2.3, leaves no time for this bug to be completed in the same release. Moving it to future. 78552 8 libertad.gonzalez.de.la.cruz 2017-12-06 18:05:27 +0000 QA needs to analyse this from the begining