On Sat, Mar 17, 2018 at 10:42:40AM -0700, Dmitry Torokhov wrote: > On Fri, Mar 16, 2018 at 08:40:02PM +0000, Nick Dyer wrote: > > On Thu, Mar 15, 2018 at 04:56:21PM -0700, Dmitry Torokhov wrote: > > > Ah, OK, I see. I would really like to drop this > > > pdata->suspend_mode stuff and I do not want to create > > > "pixel-screwed-up" property either... I guess for the time being > > > I'll put a DMI quirk for Link to restore T9 control method, and > > > then look into cleaning it all up. We have quite a bit different > > > code in chromeos kernel trees and I'd like to reconcile > > > it. > > > > Yes, it would be great to get rid of it. The driver does have the > > ability to download configuration via the firmware loader interface. > > So you would be able to grab a copy of the config by saving it with > > mxt-app, tweak it to ensure that the T9 CTRL byte is set correctly, > > then ship it somehow (presumably it could be added to > > linux-firmware). This would override what's currently stored in > > NVRAM on all those units and mean we could remove the T9_CTRL stuff. > > We can't really rely on people fetching updated config. Do you think we > could see if the device has only T9 and not T100 and if coming out of > suspend the T9 CTRL byte is 0 we overwrite it with the 0x83? I think that all we need to do is add something to mxt_read_t9_resolution (and probably rename it to mxt_init_t9_config) that reads the 1st (CTRL) byte, and if it's zero, writes 0x83 (and probably a dev_dbg() wouldn't go amiss) Also call the same logic on reset (look for "Detect reset"), because that wipes out the config. Once we've done that, we can get rid of the MXT_SUSPEND_T9_CTRL and use the normal T7 power up/down logic for suspend/resume on all devices. FWIW there may be two instances of T9, but I've never seen a device that actually had two screens and it's not supported really anyway with this driver. N -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
