New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 599928 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Apr 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 3
Type: Bug

Blocking:
issue 571088



Sign in to add a comment

add touchpad to list of possible_labels from chromeoshwid

Project Member Reported by kevcheng@chromium.org, Apr 1 2016

Issue description

Hey Keith,

Would it be possible to add 'touchpad' to the list of labels returned in dut_labels and also in possible_labels?  The current label detection mechanism takes too long and using hwid labels would be a great time-saver here.
 

Comment 1 by hadd...@google.com, Apr 1 2016

Certainly I can do that for you.

Would you like me to rename "board" to "device" is the current API also ?

Do you want a list of possible "boards" as specified in GoldenEye ?

It is easier to make changes all at one time why I am asking to try and group things together.

> Would you like me to rename "board" to "device" is the current API also ?
Could you use 'variant' instead?

> Do you want a list of possible "boards" as specified in GoldenEye ?
No, I don't think it's necessary right now.

Thank you!
Blocking: 571088

Comment 4 by hadd...@google.com, Apr 1 2016

I had already added board before I saw your email - I can take it out if it is a problem, I went through the definitions of boards in GE and from the RegExp match you will only get a single board ( and it should do the right thing for complex cases like alex and alex_he )

Small nit - how about calling it device_variant so it can be separate from board_variant ( cheets/freon/shark ) but I do not feel too strongly about it, just trying to make things less confusing.


Some examples on staging for you to look at :

Gnawty+
https://www-googleapis-staging.sandbox.google.com/chromeoshwid/v1/dutlabel/GNAWTY%20D6A-F3U-627?key=AIzaSyBXTK_tjV051BIyBdRcYNizi5D4i8YNqnY

Jaq
https://www-googleapis-staging.sandbox.google.com/chromeoshwid/v1/dutlabel/JAQ%20D25-Q6E-A4A-A6A-A6R?key=AIzaSyAouOjKEwUJTZ4pZi8nNr8uxpUA0ZcK2pw

Panther ( no touchpad )
https://www-googleapis-staging.sandbox.google.com/chromeoshwid/v1/dutlabel/PANTHER%20F5I-N22?key=AIzaSyAouOjKEwUJTZ4pZi8nNr8uxpUA0ZcK2pw

If you see errors let me know sometimes I have to kick the staging enviroment.
Thanks for the quick turnaround! I wish I had gotten to you sooner, I had something slightly different in mind.

Leave what you were doing already with 'board' and just rename 'board' to 'variant'.

so for the example of Jaq, we'd just get:
{
   "name": "variant",
   "value": "veyron-jaq"
}

And for Gnawty+/Panther, those example look good, just remove the 'board' label.


And for the touchpad label, can you just leave it as a standalone label like touchscreen (no value, only name)?  Unless Katherine prefers this new format.

Katherine?  

Comment 6 by hadd...@google.com, Apr 1 2016

Ok - board has been removed.
What was previously incorrectly called board is not called variant.
I removed the value for touchscreen and touchpad ( touchscreen should always have had a value also )

Samus link - with touchpad and touchscreen
https://www-googleapis-staging.sandbox.google.com/chromeoshwid/v1/dutlabel/SAMUS%20C25-D4M-K5B?key=AIzaSyBXTK_tjV051BIyBdRcYNizi5D4i8YNqnY

Just a clarification - jaq is the hardware what we are now calling variant, veyron-jaq is the software that runs on jaq ( would be called the board confusingly )

I think everything is correct, let me know if you want further changes if not I can send my CL out for review and push to production when that is complete.
I'm ok with the standalone touchpad/touchscreen labels like what we have today
That looks great, is it all right to leave out the 'value' for touchpad/touchscreen labels?
Done - I can also make the value just touchpad / touchscreen if that makes it easier for you.
That's all right, the logic I have currently is if the value is empty, I create the label with just the name.

Thanks Keith!
Status: Fixed (was: Untriaged)
Code is checked in and pushed to production.
Labels: VerifyIn-51
Project Member

Comment 14 by bugdroid1@chromium.org, Apr 14 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromiumos/third_party/autotest/+/9fe3e4e9796096a7a4686f44f4a79f497b724dc4

commit 9fe3e4e9796096a7a4686f44f4a79f497b724dc4
Author: Kevin Cheng <kevcheng@chromium.org>
Date: Mon Apr 04 19:10:38 2016

[autotest] Remove TouchLabel from CrosLabel.

The label is being replaced by hwid as the source of truth.  This
is done primarily because the TouchLabel detection method takes too
long (~20 sec) and is an inhibitor for adding the label auto-update
as a verifier.

BUG= chromium:599928 
TEST=locally tested on gnawty, touchlabel is still being detected
via hwid.
CQ-DEPEND=CL:331329

Change-Id: I858bf89246e9f7c08675a24d2776db3ff1339bba
Reviewed-on: https://chromium-review.googlesource.com/336899
Commit-Ready: Kevin Cheng <kevcheng@chromium.org>
Tested-by: Kevin Cheng <kevcheng@chromium.org>
Reviewed-by: Richard Barnette <jrbarnette@chromium.org>
Reviewed-by: Katherine Threlkeld <kathrelkeld@chromium.org>

[modify] https://crrev.com/9fe3e4e9796096a7a4686f44f4a79f497b724dc4/server/hosts/cros_label.py

Components: Infra>Client>ChromeOS
Labels: -Infra-ChromeOS
Labels: VerifyIn-52
Closing... please feel free to reopen if its not fixed.
Status: Verified (was: Fixed)

Sign in to add a comment