On Fri, Jan 10, 2025 at 01:45:03PM +0200, Jarkko Nikula wrote: > On 1/10/25 1:26 PM, Mika Westerberg wrote: > > Hi, > > > > On Fri, Jan 10, 2025 at 02:31:26AM -0600, R Ha wrote: > > > Hi, > > > > > > Sounds like a good idea. I'm a little worried I'm missing something, > > > so I think being able to check my earlier answers will help as well. > > > I'm sending the entire output as attachments, but let me know if it's > > > better to upload them somewhere and paste the link instead. Some of > > > the ssdt* files are missing, but they're empty files so Gmail won't > > > let me attach them. > > > > Thanks for sharing! Okay checked now dsdt.dsl (the other files are not > > relevant here) and what I can tell the device is supposed to be run at 400 > > kHz. I suspect this is what Windows is doing as well, there is nothing that > > indicates otherwise. > > > > And since this is a standard I2C HID device it should just work (as it does > > not require any vendor specific driver even in Windows). > > > > Only thing I can think of that affects this is the LCNT/HCNT and SDA hold > > values of the I2C designware controller (and maybe the input clock) but > > there is nothing in the ACPI tables that set these so it could be that the > > Windows driver uses different values for those and that explains why it > > works better there. > > > > @Jarkko, do you have any input here? If we cannot figure a better way then > > I don't see other option than to add this quirk. > > Unfortunately I don't have idea. Okay thanks anyway! Then I don't see any other option than adding that quirk. @R Ha, can you then submit a new version of the patch with the latest details in the changelog?
