| Summary: | input subsystem testing | ||
|---|---|---|---|
| Product: | [QA/Testing] Runtime Testing | Reporter: | Darren Hart <dvhart> |
| Component: | general | Assignee: | Unassigned <unassigned> |
| Status: | NEW --- | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | Medium | CC: | alexandru.c.georgescu, benjamin.esquivel, bluelightning, randy.macleod, ross.burton, sgw |
| Version: | unspecified | ||
| Target Milestone: | Future | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
| Bug Depends on: | 10604 | ||
| Bug Blocks: | |||
|
Description
Darren Hart
2014-10-21 18:41:08 UTC
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). Yeah I didn't get any time to actually do this. Moving to 1.9M2. 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. 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. 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. Ack. 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. QA needs to analyse this from the begining |