On Saturday 12 November 2016 15:48:14 Chris Diamand wrote: > Hi, and thanks for your reply. > > > Hi! This looks very fragile. We really cannot test presence of some > > device by DMI string "To Be Filled By O.E.M." or by "WhiteTip > > Mountain1 Fab2". Look at other dmi detection code. We match full > > device and vendor. > > Do you think it's likely to match too many or too few machines? I can > match the device and vendor instead, but I think that would have > more false positives (DMI_SYS_VENDOR and DMI_PRODUCT_NAME are "Intel > Corporation" and "Sharkbay Platform"). > > Here are all the DMI fields we can use, with their values on my > (former) BYD machine. As you can see, none of them are particularly > helpful. However, I *hope* that most other manufacturers fill them > in, so I'd be surprised if there are many false positives. > > DMI_BIOS_VENDOR: American Megatrends Inc. > DMI_BIOS_VERSION: 5.6.5 > DMI_BIOS_DATE: 06/30/2015 > DMI_SYS_VENDOR: Intel Corporation > DMI_PRODUCT_NAME: Sharkbay Platform > DMI_PRODUCT_VERSION: 0.1 > DMI_PRODUCT_SERIAL: System Serial Number > DMI_PRODUCT_UUID: 03000200-0400-0500-0006-000700080009 > DMI_BOARD_VENDOR: Topstar > DMI_BOARD_NAME: WhiteTip Mountain1 Fab2 > DMI_BOARD_VERSION: Fab2 > DMI_BOARD_SERIAL: 1 > DMI_BOARD_ASSET_TAG: Base Board Asset Tag > DMI_CHASSIS_VENDOR: To Be Filled By O.E.M. > DMI_CHASSIS_TYPE: Laptop > DMI_CHASSIS_VERSION: To Be Filled By O.E.M. > DMI_CHASSIS_SERIAL: To Be Filled By O.E.M. > DMI_CHASSIS_ASSET_TAG: To Be Filled By O.E.M. Sorry, but this DMI information does not tell anything about presense of BYD touchpad. Moreover such generic matches like "Sharkbay Platform" or "To Be Filled By O.E.M." can be found on any other non-BYD touchpad devices and it just cause lot of other problems... Also what about devices which do not have "To Be Filled By O.E.M." and have BYD touchpad? You basically break support for such devices. I'm sure such logic just cause problems in future... How is windows detecting presence of BYD touchpads? Should we use something similar? Or are not there some (public) documentation about it? > > If we really have a problem when byd detect incorrect detect some > > non-byd device as byd, we either needs: > > > > 1) extend detect code to include also parts of init sequence (this > > should > > > > fix problem on wrongly detected non-byd devices, but init code > > on them will take longer) > > I agree. What I am trying to achieve with this patch is to fix 99% of > cases where we wrongly detect a non-BYD device. Still I think this is just ugly and non-working hack, not a proper solution. But I'm not in position to decide, so wait what will Dmitry (as maintainer) wrote about it... > There may still be a > few false positives, but for those we can apply Richard's patch, > which moves the whole init sequence to byd_detect(). > http://www.spinics.net/lists/linux-input/msg45539.html > > This will slow down detection of normal mice, but if my DMI patch is > also applied, it will only affect a tiny fraction of users. Maybe you should check if there is device or port DMI information? dmidecode will print it, but I sceptic about it... > Also, Richard's patch would fix the even rarer case of someone trying > to use a mis-detected mouse on an actual BYD device. I would prefer slower, but correct detection. Not just some nonsense heuristic based on "To Be Filled By O.E.M.". > > 2) or use another detection technique, which will address above > > problem ( > > > > your "To Be Filled By O.E.M." is not good; maybe looking at > > ACPI?) > > That could also work, but I wouldn't be able to write such a patch as > I no longer have access to the device. Then we need acpi DSDT dumps from those machines... And check if acpi based enumeration is more useful or not... > Anyway, in summary; the ideal solution seems to be DMI matching + > extended detection sequence - this patch is the first part. -- Pali Rohár pali.rohar@xxxxxxxxx
Attachment:
signature.asc
Description: This is a digitally signed message part.
