| ab03ed85a8ca7f99608e872d0717c53d3742d031 |
|
03-Oct-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Touch FW test: fix handling of no-variation tests
Some tests have no variations, so the variation object is None, which
can result in some crashes since the script was assuming that they were
strings. This patch checks for None before trying to determine what it
should do with the function generator to prevent crashes.
BUG=none
TEST=manually tested
Change-Id: Ieb507b2fca6b478e257ac33cfad1f36cbc94c3d3
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/221431
Reviewed-by: Andrew de los Reyes <adlr@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 42bc23b188cdf856d24494842909ac0e0930b257 |
|
19-Sep-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Add a manual noise test mode to the Touch FW tests
Elan wants to reproduce our robotic noise test using their robot. After
some brainstorming with them on the best way to do this, we devided that
actually making a mode that does the noise test "manually" would
probably be easiest. Then they can program their robot to simply touch
the pad for a few seconds, raise up, wait a few more seconds, and then
hit the spacebar. It should work just fine I think and is a lot easier
than rewriting the robot wrapper classes to support their robot.
This CL adds a new flag "-f" that allows you to indicate to the test
suite that you do, in fact have a function generator attached even
though the robot may not be connected. So to run the extended noise
test manually you would run:
DISPLAY=:0 python main.py -m NOISE -f
The test will controll the function generator automatically for you, and
then you are manually required to perform the gesture.
BUG=chromium:416062
TEST=manual testing. The new mode works and the regular modes that
existed before seem to still work as expect as well
Change-Id: I12110ca30422f0d3f7455654253675834fc19d9c
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/219101
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| dfeafca16e4aacb865b51768f607a1a5a2db956c |
|
20-Aug-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Fix reference to MTBSanityValidator
The reference to MTBSanityValidator in test_flow was missing the module
name and causing crashes. This CL just adds the module name.
BUG=chrome-os-partner:30965
TEST=I ran the FW test on the robot. It would crash immediately before,
but with this patch it worked fine.
Change-Id: I88536011af38310efe1038cf198832c8d37fd37f
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/213272
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 45f891b832de8f1c94e1006478fb557cd341aa57 |
|
28-Jul-2014 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: take MtbSanityValidator as a prerequisite
If the MtbSanityValidator fails in a test, it indicates the existence
of some critical problems. The rest validators of the test would not
be executed because some unexpected problems or results might be
incurred.
BUG=chrome-os-partner:30965
TEST=Record gesture files on a chromebook machine.
$ cd /usr/local/autotest/tests/firmware_TouchMTB/
$ DISPLAY=:0 python main.py -m complete
Before pressing ENTER for the 2nd command above, place 2 fingers on
the touchpad. Then press ENTER. It would only show the test results
about MTB Sanity on the right side of the gesture capturing window.
There are no test results about the other validators.
. . .
MtbSanityValidator
# fingers: 2
slot 0:
MT_TOUCH_MAJOR= 254
MT_TRACKING_ID= 4
MT_PRESSURE= 52
MT_POSITION_X= 573
MT_POSITION_Y= 299
slot 1:
MT_TOUCH_MAJOR= 254
MT_TRACKING_ID= 5
MT_PRESSURE= 57
MT_POSITION_X= 1384
MT_POSITION_Y= 421
# MTB # errors: # 473
FINGER_LEAVING_BEFORE_ARRIVING: 2
ASSIGN_ATTRIBUTES_BEFORE_ARRIVING: 471
criteria_str: == 0
score: 0.000000
. . .
Change-Id: Ic89fb78eb36ef911521adf094eafb9857e218e32
Reviewed-on: https://chromium-review.googlesource.com/210791
Reviewed-by: Charles Mooney <charliemooney@chromium.org>
Commit-Queue: Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| b0612e11b87281c1ab8ab95d3c47de2601a9df26 |
|
16-Jul-2014 |
Mindy Huang <mindyh@chromium.org> |
Added a noise mode to the robot.
In noise mode, the robot does a fine-grain frequency test on the device.
It sweeps from 0Hz to 1MHz in 400Hz intervals, for a total of 2500 tests
in about 4 hours.
BUG=chromium:394075
TEST=Manually with robot on a lumpy
Change-Id: Iaf5901923f42cbd41c0a263a0431b512f6cdbb36
Signed-off-by: Mindy Huang <mindyh@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/208485
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| dee21b175441da05e032ece48d774b4107569c07 |
|
29-May-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Sort the gestures by finger requirements
Currently the gestures are run in what amounts to a random ordering.
This was fine before, but since the robot is running the tests now, we
can speed things up and decrease the odds of failures/damage by ordering
them intelligently. Fingertip swapping is slow and the most dangerous
part of the test in terms of likelihood for failure as well as actual
damage to the robot. Therefore, we would like to minimize the number of
fingertip swaps if possible.
This patch alters the touch FW test so that it will always run the
gestures in an order that is sorted based on fingertip usage. The order
is arbitrary (whatever the default python sorting algorithm is when the
keys are lists of ints) but the important thing is that all the tests
with the *same* fingertips are run in succession. This will minimize
the number of fingertips swaps, saving time and making the test more
stable.
BUG=chromium:378956
TEST=manually tested. The ordering was efficient and the test still
rand as normal (just in a different order than before)
Change-Id: I8b99a8033e2cfb43514ed65c1ca5d1fe5763a33a
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/202128
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 8b3cb003be644a2b78689346628122bb5b3f2f6b |
|
15-May-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Consider empty logs for tap tests as legal
A previous CL made it so that if a robot gesture returned no events the
test would continue on instead of halting. This is great, but in the
case of "tap" tests, it's not exactly what we'd like. For the tap
tests, we're trying to see *if* the pad saw the finger, so when the pad
fails to register a finger, we don't want to just skip it, we want to
consider it a failure and save that result.
This CL adds an exception to the validators that allows empty logs to
get validated if it's a robot test that's doing taps.
BUG=chromium:371505
TEST=I ran missed tap tests and the tracking ID count validator was
effected instead of simply skipping the log. On other gestures that
failed (non-tap) the gesture was skipped outright and didn't effect the
results other than a blank placeholder that was put in the html report
which is nice actually as it acts as a reminder that the test wasn't run.
Change-Id: If0670a3550f4e1bc272d4139ba146a8e4ce416be
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/200095
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 2cbb23bb88733c3e0a40f7d17681ed957b54ce27 |
|
13-May-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Add a quickstep flag to the touch FW test
It's common to want to check the latency of a system without running the
full (long) FW test on it. This CL adds a nice, simple way to do that
without having to know how the code works and comment out parts you
don't want. Now there is an additional '-q' or '--quickstep' flag you
can pass to the test suite when you run it. If you do it overrides the
list of gestures and only runs the latency test.
BUG=chromium:372895
TEST=I used it both with and without the flag and it seems to do the
job.
Change-Id: Ia05b771c00341447e253d56a13a7c08e967d8401
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199495
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| af9472281594241369d693c45722c6a8b2310840 |
|
09-May-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Fix hangs in TouchMTB FW test on no gestures
Previously, the timeout callback that wraps up a gesture in the Touch FW
test is only activated when the DUT sees the first event come in from
the touchpad. This presents a problem in two situations:
1.) The robot decides it is incapable of a gesture. This is possible
for some of the two-fingered gestures depending on the shape of
the touchpad. Obviously, it's be better if it never happened, but
it will happen sometimes and we don't want it to crash when it
does.
2.) There is a test (such as detecting taps) where the failure mode is
that no events are ever reported by the touchpad. In this
situation, even though the robot did what it was supposed to, the
DUT never sees anything and so it just hangs.
with this change both kinds of failures are simply ignored. A blank
entry is added to the html report and it's skipped when calculating
the summary scores.
For case number 1, this is the desired behavior. (You shouldn't hold it
against the pad that the robot can't do the gesture) However for case
number 2, this is in fact the fault of the touchpad and should be
reported as a failure. This CL doesn't do it, but at least it keeps it
from hanging, so this is the first step. I will work on a fix for #2
next.
BUG=chromium:371508
TEST=manual testing on a device that was exhibiting both of these
failure modes. The failed tests responded as described above and
everything else worked as usual
Change-Id: I174b225c4375b8aa1d74292cd65c4653a27560ce
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/199148
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 3ceb6419c90576ba7df8cee03d4b42d38d1b6d00 |
|
05-Mar-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Adding a drag-latency test to the Touch FW test
A drag latency test has been part of our touch qualification process for
a while now, but has always been run by hand. With Quickstep, this
should be able to be performed automatically as with any other
gesture/validator that we check. The operator will just need to set up
the laser across the pad before running the test.
This CL adds in the robot support for the Quickstep gesture and a new
validator that imports in the latency calculation software from the
touchbot project and computes the drag-latency using the touch data the
firmware collected and pulling the laser data out of the Quickstep sysfs
entries. If there is no Quickstep present, the test will report a
failing dummy value to indicate this, otherwise you would need the
Quickstep device to run the FW test, which is something we don't want to
be a requirement.
BUG=chromium:349174
TEST=Manually ran the test with and without the Quickstep plugged in and
the gesture ran smoothly and the computations worked without crashing
Change-Id: I638da3f837e86d6cf40da3e552c7d56b23e51ee1
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/189502
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| bc9dba0f212df1b31ed43032c68f5e07e9ee9974 |
|
01-Mar-2014 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: add version info to test logs
When recording gestures files or generating the test summary,
we would like the version info to be prepended to the test logs,
including the standard output, the html report, the pickle log,
and the summary report.
BUG=chromium:315787
TEST=Install the test on a chromebook machine as a first step.
Then, in the chroot of your host:
(cr) $ cd .../site_tests/firmware_TouchMTB
(cr) $ ./version.sh -r ${MACHINE_IP}
On the chromebook, record a few gestures, and then press 'x' to exit.
$ DISPLAY=:0 python main.py -m complete
Now, check the version info in the following files:
$ cd /var/tmp/touch_firmware_test/latest
$ less touch_firmware_report-xxxx
$ less touch_firmware_report-xxxx.html
$ less touch_firmware_report-xxxx.log
The version info should show up in the first few lines look like
test_version: 2014-02-28.06:46:04 5db2d13bf7ff0e56c652213434f581ce6d7a65ee
Change-Id: I549d97574dd44d2cdd7eea7efe0de85a5fd67f66
Reviewed-on: https://chromium-review.googlesource.com/188562
Reviewed-by: Charles Mooney <charliemooney@chromium.org>
Tested-by: Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 42740f2c8a15b00c69847855bf477270f4b84cf2 |
|
12-Feb-2014 |
Charlie Mooney <charliemooney@chromium.org> |
Set Touch FW test to use visible clicks in mtplot
The ability to make visible marks for clicks has just been added to
mtplot. This allows the FW test to record a better version of the
mtplot logs where you can actually see everything that happens.
Previously clicks clear the display, which can sometimes mean we lose a
lot of debugging info. With this change, clicks don't clear the screen,
but are shown as rectangles in the output image.
BUG=chromium:342433
TEST=I manually ran the FW test suite and clicked the pad during a test,
the image showed the little boxes instead of clearing the display.
CQ-DEPEND=Ic67775cc9dbbf73858d1d7c9051ea6d8145bc6c4
Change-Id: I1d6bed87188f8dc84921ea989ad2db5793f0596e
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/186107
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 3bad937cb81c5c22183024c7bc67575cd099b051 |
|
30-Dec-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: should save the logs and reports after recording
The test flow should output logs and html report after recording
gestures. Currently, it only does the output in the replay mode
which is a bug.
BUG=chromium:331015
TEST=Perform a recording round, and check that the html file
contains all the gestures images and logs.
$ cd /usr/local/autotest/tests/firmware_TouchMTB
$ python main.py -m manual
Type "/tmp" in Chrome browser's omnibox. And check the html report
whose name looks like "touch_firmware_report-xxxx.html". Verify that
there are gesture images and logs in the html file.
Change-Id: I1ec4dadaab4bb9edd01fc9b76ea1affedc872fd2
Reviewed-on: https://chromium-review.googlesource.com/181235
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 79009095b5857565709897cf01a23c15e8fefdb5 |
|
05-Dec-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: show test results in html report only when files exist
When a gesture set is replayed, it generates a new html report file
automatically. However, if some of the gestures/variations files are missing,
empty blocks are shown for those missing ones in the html report.
In replay mode, it is desirable to only show the test results of those
existing files.
BUG=chromium:326404
TEST=Perform the following steps
$ cd /usr/local/autotest/tests/firmware_TouchMTB
Remove all the files about one_finger_tracking
$ rm tests/logs/link/20130806_221321-fw_1.0.AA-robot/one_finger_tracking.*
Now replay the log
$ tools/machine_replay.sh -b tests/logs/link/
Observe that there are no empty blocks about one_finger_trackig.* in
the beginning of the html report file
/tmp/touch_firmware_report-link-fw_1.0.AA-complete-xxxx.html
where xxxx represents the current date-time.
Change-Id: I67e365a25c421317d08f3b4b1aa77697acf2d511
Reviewed-on: https://chromium-review.googlesource.com/179032
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 3162c02ea4a2287fc77436ba28f2c9c83349b63e |
|
05-Dec-2013 |
Charlie Mooney <charliemooney@chromium.org> |
Touch FW test: Never try use robot in MANUAL mode
Errors were showing up when the MANUAL portion of the test was being run
because the touchbotII robot wrapper was still trying to talk to the
robot even in manual mode. This CL just adds a check to immediately
abort any robot controls unless the FW test is in ROBOT mode and pushes
all if the robot logic into the robot wrapper to avoid confusion in
test_flow.py.
BUG=chromium:326237
TEST=Ran the test and the errors went away. The test worked fine too
Change-Id: Ic4fc607b799d88325d47eb7a7e2f86ba82acae0c
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/178970
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| c0d30cbdfb45cfb800689451f29fe37345c66f48 |
|
21-Nov-2013 |
Charlie Mooney <charliemooney@chromium.org> |
Switching the Touch FW test to the new Robot
The touchbotII robot wrapper has been under development for a while now
and seems to be quite functional. As such I would like to switch the
test over to use it now. This patch removed the old robot wrapper and
replaces it with the one for the new robot.
The current state of the robot test with the new robot is that it can do
the same tests that the old robot could. The only way to really iron
out the kinks in it now is to start actually using it, I think. More
tests will be added as this robot is much more flexible than the old
one, but replacing the old functionality was the first milestone here.
BUG=chromium:308162
TEST=I ran the full fw test using the new robot on a Lumpy in the lab
and everything worked.
Change-Id: Ife9bd73850511b4c131fc16d850e1798d686f662
Signed-off-by: Charlie Mooney <charliemooney@chromium.org>
Reviewed-on: https://chromium-review.googlesource.com/177481
Reviewed-by: Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: David James <davidjames@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| ad3136c03a931b4c1742cdec472780be15f7e1ed |
|
12-Aug-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: replay with a mocked device
It is handy and sometimes essential to be able to replay the test
logs captured from a platform on another platform.
When replaying logs, the board on which the logs were captured could
be different from the board of the chromebook currently used. Hence,
the correct board should be extracted from the log specified in the
replay directory. The following priority is used to find the device
description file used to mock the particular touch device for that
board:
(1) use the device description file in the replay directory
(2) use the device description file found in tests/device directory
However, if "-d/--system_device" command line option is specified, use
the system touch device found on the chromebook instead as before.
BUG=chromium:274204
TEST=Replay the lumpy logs on both lumpy and link. Observe that
their summary reports are exactly the same.
$ cd /usr/local/autotest/tests/firmware_TouchMTB
$ tools/machine_replay.sh -b tests/logs/lumpy -s
$ ./summary.sh -d /tmp -m f
Change-Id: I95a39d0ead821de9379e2f3a26f19e42a9c829b9
Reviewed-on: https://gerrit.chromium.org/gerrit/66345
Reviewed-by: Charlie Mooney <charliemooney@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 09890dba0014937e0be1d75d1a46c05dd16cc6b8 |
|
07-Aug-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: fix the replay error about max recursive depth exceeded
If we record the gestures using the robot with 3 iterations, and then
replay the gestures, it may result in the max recursive depth exceeded.
The gesture recording program is an event driven program in which the
X window system will receive and handle incoming events. However, our
replay program used a recursive function call to replay gesture files.
When the number of gesture files is large, this may result in an error
of max recursive depth exceeded.
A simple solution is to replay the gesture files in the same event
driven manner that is used when recording the gesture files. This
would reuse most of the flow control logic. This is achieved
primarily by registering a timeout callback in the method
_setup_this_gesture_variation() when replaying.
BUG=chromium:271279
TEST=Record gesture files with 3 iterations using the robot.
And then replay the gesture files on the same chromebook machine.
Observe that the replay finish correctly without the max recursive
depth exceeded problem.
Change-Id: Ib6cb2872d2e62b7e533bcf7e214dce57806e71bc
Reviewed-on: https://gerrit.chromium.org/gerrit/65560
Reviewed-by: Charlie Mooney <charliemooney@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 1dfb83324d02b4f82a8ee2bd32525e78197adf86 |
|
31-Jul-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: reverse coordinates for touchscreen in robot mode
When performing the touchscreen tests using the robot, the device is
placed upside down and is rotated 180 degrees. We need to reverse the
coordinates to make correct gestures.
BUG=chromium:266720
TEST=conduct the touchscreen firmware tests with the touch robot.
$ cd /usr/local/autotest/tests/firmware_TouchMTB
Conduct the touchscreen tests with 1 iteration using the robot.
$ DISPLAY=:0 python main.py -m robot -i 1 --touchscreen
Observe that the robot performs the gestures correctly with respect
to the touchscreen's orientation.
Change-Id: Ic01f2612942585bb1f72da42ff986b8adb50306d
Reviewed-on: https://gerrit.chromium.org/gerrit/64180
Reviewed-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 1e4a6cce6769e50e5ef33dafd228c46ec6e3bc0e |
|
31-Jul-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: fix the replay problem due to non-existence of raw data files
When in replaying mode, the program will replay existing data files
in the specified folder. If there is no existing data file(s) for a
gesture, the gesture will be skipped. Currently, there is a bug.
If a gesture is skipped owing to the lack of raw data files, the
gesture test results are still displayed using the previous mtplot
image without any validators test results in the html report.
In this patch, we fix this bug by resetting the gesture image
when all contents of current test has been flushed to the html
report. In this way, the gesture image will not be used repeatedly
by mistake.
BUG=chromium:266721
TEST=Replay the raw data files on a lumpy chromebook.
$ cd /usr/local/autotest/tests/firmware_TouchMTB
$ tools/machine_replay.sh -b tests/logs/lumpy/ -s
The replay is expected to finish within half a minute. Check the
/tmp/touch_firmware_repot_xxxx.html report files using chrome.
It should display the html report correctly without any empty
validators test results and wrong mtplot images.
Change-Id: I281fc8c1ecdaf3c2a0fd8dd43de45ca59946c4c8
Reviewed-on: https://gerrit.chromium.org/gerrit/64179
Reviewed-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 1fd993155b6d1c6996daafd5789101d3342c7bc9 |
|
01-Jul-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: do not upload data by default
Since our partners are running our firmware test suite now, we
should disable uploading of any data to google servers by default.
To upload the data later when needed, use the option "-u/--upload"
to specify a test result directory under
"/var/tmp/touch_firmware_test". Refer to the example below for
more details.
BUG=chromium:254992
TEST=Conduct the firmware tests on a chromebook machine.
$ cd /usr/local/autotest/tests/firmware_TouchMTB
$ DISPLAY=:0 OPTIONS="-m complete" python main.py
After all tests have been finished, observe that the data are not
uploaded. Instead, it displays the following messages.
You can upload all data in the latest result directory:
$ DISPLAY=:0 OPTIONS="-u latest" python main.py
You can also upload any test result directory, e.g.,
"20130702_063631-fw_1.23-manual", in "/var/tmp/touch_firmware_test"
$ DISPLAY=:0 OPTIONS="-u 20130702_063631-fw_11.23-manual" python main.py
Change-Id: Ibbcc272b0f9241e8026e8f5c2b9464e9d79d61cb
Reviewed-on: https://gerrit.chromium.org/gerrit/60742
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Reviewed-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| bb6f69b8c90e4896dd82e0266a096674c957f7db |
|
27-Jun-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: capture files for pressure calibration
In this patch, we add a new mode to capture event files for
pressure calibration.
BUG=chromium:221864
TEST=Run the test on a chromebook machine to capture event files.
$ cd /usr/local/autotest/tests/firmware_TouchMTB
$ DISPLAY=:0 OPTIONS="-m calibration" python main.py
Observe that it guides the user to record a few event files with
distinct size of metal fingers.
Change-Id: I6f65a2d3585380a51dd0e4bf6785fe55308c91c8
Reviewed-on: https://gerrit.chromium.org/gerrit/60641
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
Reviewed-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 3f245993196c7cead8716ff09633a6ad49e8b006 |
|
15-May-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: New drumroll validator
The new drumroll validator requires that all points from the same
finger should be within 2 circles of radius X mm (e.g., 2 mm).
Pass if so. Fail if all points cannot be covered by 2 circles of
radius X mm.
In order to run unit tests with a mocked device, we also allow to
create such a mocked device by passing the device description into
TouchDevice class.
BUG=chromium:241092
TEST=On a chromebook
$ cd /usr/local/autotest/tests/firmware_TouchMTB
Make sure that the following unit test pass.
$ python tests/validators_unittest.py
Change-Id: I439fc70fc8c2b1d47b3475b7013997768c326feb
Reviewed-on: https://gerrit.chromium.org/gerrit/55758
Reviewed-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| ecc254fc00e6b3504d4f7d87abad937cf73a267d |
|
07-May-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: refactor firmware_log and firmware_summary modules
Some of the code about test logs was manipulated in firmware_summary
module which made this module become messy. In this patch, we do the
refactoring by moving those code to firmware_log module and create
classes for them. In addition, we also flatten the deep hierarchy of
log dictionaries so that it is much simpler to maintain.
BUG=chromium:238039
TEST=On a chromebook
$ cd /usr/local/autotest/tests/firmware_TouchMTB
Make sure that the following unit test pass.
$ python tests/firmware_summary_unittest.py
Change-Id: Idc5a70ed28745805a4221cc20780c23da0210fb0
Reviewed-on: https://gerrit.chromium.org/gerrit/50320
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
Reviewed-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 40cb76895b4a52d85d5d2c1a25b45e49bdeb9828 |
|
06-May-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: fix some issues for replay
This patch fixes some issues for replaying raw data:
(1) Use the firmware version of the replayed files instead of that
of the real touch device since it does not record new files.
(2) Do not upload the gesture files since it is just a replay.
BUG=chromium:238039
TEST=On a chromebook. Replay an existing gesture set of which the
firmware version is not the same as the current firmware
version of the real touch device. Observes that it could
replay correctly. It does not upload the gesture files to
google storage server.
Change-Id: I5a14e94119fa28d422c6d66c00a0591ae0420174
Reviewed-on: https://gerrit.chromium.org/gerrit/50309
Reviewed-by: Charlie Mooney <charliemooney@chromium.org>
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|
| 0cbff8bf3666a81b886080f82712943e36dad95f |
|
22-Apr-2013 |
Joseph Hwang <josephsih@chromium.org> |
firmware_TouchMTB: Rename the test suite as firmware_TouchMTB
As the test suite is now applicable to both the touchpad
and the touchscreen, it is proper to rename the test name
from firmware_TouchpadMTB to firmware_TouchMTB.
BUG=chromium:234117
TEST=None. Will be combined with next patch.
Change-Id: I92ecc074023c76f7c2f292b7e22ef960d537819f
Reviewed-on: https://gerrit.chromium.org/gerrit/48781
Reviewed-by: Charlie Mooney <charliemooney@chromium.org>
Commit-Queue: Joseph Shyh-In Hwang <josephsih@chromium.org>
Tested-by: Joseph Shyh-In Hwang <josephsih@chromium.org>
/external/autotest/client/site_tests/firmware_TouchMTB/test_flow.py
|