> On Jun 8, 2016, at 2:06 PM, Tom Zanussi <tom.zanu...@linux.intel.com> wrote: > > Hi Jianxun, > > On 06/07/2016 06:46 PM, Jianxun Zhang wrote: >> The new machconfig probes USB keyboard and touch screen, and >> then sets HAVE_* variables according to detection. >> >> Detectable devices: >> USB HID keyboards (Generic Desktop) >> USB HID touch screens (Digitizer) >> >> Note: >> The intention is to have a way to provide initial formfactor >> settings in a boot procedure. That means supported keyboard >> and touch screen must be connected before machconfig runs. >> Any new connection or disconnection won't be detected until >> machconfig is executed again. >> >> Limitation: >> There could be some USB HID devices presents more than one >> usage in a single descriptor. We will add support once such >> device emerges. >> >> Some platforms may have _virtual_ devices provided by BIOS. >> It will cause false detection when they are presented as >> types we supported. We can add black list logic when it >> becomes a big concern. >> >> Fixes [YOCTO #9205] >> >> Signed-off-by: Jianxun Zhang <jianxun.zh...@linux.intel.com> >> --- >> .../recipes-bsp/formfactor/formfactor/machconfig | 37 >> ++++++++++++++++++++++ >> .../recipes-bsp/formfactor/formfactor_0.0.bbappend | 1 + >> 2 files changed, 38 insertions(+) >> create mode 100644 common/recipes-bsp/formfactor/formfactor/machconfig >> create mode 100644 common/recipes-bsp/formfactor/formfactor_0.0.bbappend >> >> diff --git a/common/recipes-bsp/formfactor/formfactor/machconfig >> b/common/recipes-bsp/formfactor/formfactor/machconfig >> new file mode 100644 >> index 0000000..17d4978 >> --- /dev/null >> +++ b/common/recipes-bsp/formfactor/formfactor/machconfig >> @@ -0,0 +1,37 @@ >> +# Note: super user permission is required to run usbhid-dump >> +# successfully. >> + >> +# HEX keys are according to USB HID spec and USB HID usage table >> +# We could add more keys as needed in the future. >> + >> +# checker for generic USB HID keyboard >> +USBHID_KBD_CMD="grep -E '^ 05 01 09 06'" >> + >> +# checker for touch screen >> +USBHID_TS_CMD="grep -E '^ 05 0D 09 04'" >> + >> +# It may not be very accurate. Here we only look for first two lines >> +# of a descriptor section. Example: >> +# >> +# 001:003:000:DESCRIPTOR 1460501386.337809 >> +# 05 01 09 02 A1 01 09 01 A1 00 05 09 19 01 29 03 >> +# 15 00 25 01 95 03 75 01 81 02 .. .. .. .. .. .. >> +# .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. >> +# >> +# By doing so we elimiate false matches when HEX keys are in the lines >> +# in the middle of whole descriptor section. >> + >> +USBHID_DUMP_OUTPUT=$(usbhid-dump -e descriptor|grep -A1 DESCRIPTOR) >> + >> +if echo "$USBHID_DUMP_OUTPUT"|eval $USBHID_TS_CMD &>/dev/null; then >> + HAVE_TOUCHSCREEN=1 >> +fi >> + >> +if echo "$USBHID_DUMP_OUTPUT"|eval $USBHID_KBD_CMD &>/dev/null; then >> + HAVE_KEYBOARD=1 >> +else >> + # config script in OE will set HAVE_KEYBOARD=1 >> + # if we don't set any value. We have to explicitly >> + # tell it when keyboard is not detected. >> + HAVE_KEYBOARD=0 >> +fi > > What if usbhid-dump doesn't exist? In that case, not detecting a > keyboard doesn't mean there isn't one. > > I think Saul suggested you check for usbhid-dump first and then exit > having touched nothing that would deviate from the defaults. oops, I had another talk with Saul about default value set in config. My previous comment is an answer for that totally different question :-( Yes, I agree with this and actually think the new detection should be skipped when any errors are tossed by the command, including the case cmd doesn’t exist.
Put that line "USBHID_DUMP_OUTPUT=$(usbhid-du...” in an if statement should resolve such problems. I will submit another V3 with some tests Thanks lot! > > Tom > >> diff --git a/common/recipes-bsp/formfactor/formfactor_0.0.bbappend >> b/common/recipes-bsp/formfactor/formfactor_0.0.bbappend >> new file mode 100644 >> index 0000000..72d991c >> --- /dev/null >> +++ b/common/recipes-bsp/formfactor/formfactor_0.0.bbappend >> @@ -0,0 +1 @@ >> +FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}:" >> > -- _______________________________________________ meta-intel mailing list meta-intel@yoctoproject.org https://lists.yoctoproject.org/listinfo/meta-intel