Hi Hans, Thanks for writing this patch, I've just tested it and the wrong state issue is fixed. The switch is in the correct state after suspending no matter the state before suspending. I've seen forums posts of people experiencing the same issue on other models, so I'm sure it will help them as well. For the issue where the switch stops responding, it did happen once but after rebooting I can't get it to happen again. It's hard to know for sure since it happens randomly, or maybe I didn't have the patched module actually loaded when it did occur. I'm guessing it probably should have happened by now, but I can report back if it eventually happens again. I really appreciate you taking the time to work on this. Thanks, Arnold On 2023-12-03 10:41, Hans de Goede wrote: > Hi Arnold, > > I was wondering what the status of this is. > > Did you manage to find some time to test the patch > which I attached to my previous results ? > > And if yes, what were the results? > > Regards, > > Hans > > > On 11/20/23 15:18, Hans de Goede wrote: >> Hi Arnold, >> >> Thank you for reporting this. >> >> Unfortunately removing the Dell Inspiron 7352 from >> the dmi_switches_allow_list will not help. >> >> The intel-vbtn driver now a days also creates an input-device >> with a tablet-switch upon receiving the first tablet-switch >> related event, to avoid needing to maintain an ever growing >> list of devices on the allow-list. >> >> And since the Dell Inspiron 7352 does have a somewhat working >> tablet-mode-switch it does send such events. So removing it >> from the allow-list will only result in the creation of >> an input-device for the tablet-mode-switch being delayed till >> the first event. >> >> Now we could add a dmi_switches_deny_list for this purpose, >> but first lets see if we can fix things. >> >> On 10/29/23 20:52, Arnold Gozum wrote: >>> Hi, sorry for the delayed reply. Your patch doesn't seem to work, I >>> still have the issue where the switch is in the wrong state after >>> suspend/resume. >> >> Ok, so this does sound like the issue where the switch completely >> stops reporting state-changes is fixed with the addition of >> the extra "VBDL" call ? >> >> I think that the wrong mode after suspend/resume is just a matter >> of manually checking the mode after a suspend/resume. >> >> Can you give the attached patch a try and see if that fixes things ? >> >> Regards, >> >> Hans >> >> >> >> >>> And yes, it's been a while, and I believe the issues did exist during >>> that time however it was easy to ignore/forget since I'm on X11 where >>> libinput doesn't respond to tablet mode switches, so I neglected to >>> report the issue for a while. Also, about the BIOS, I'm a little >>> hesistant to update it since I don't have a battery. I have version A11 >>> and the newest is A15, but Dell's update notes only mention security >>> fixes, so maybe it doesn't matter. >>> >>> On 2023-10-17 22:05, AceLan Kao wrote: >>>> Arnold Gozum <arngozum@xxxxxxxxx> 於 2023年10月18日 週三 上午8:53寫道： >>>>> >>>>> Hi, >>>>> >>>>> In Linux 5.11, Dell Inspiron 7352 was added to the >>>>> dmi_switches_allow_list as it is a 2-in-1 which reports a chassis type >>>>> 10 (actually it was me who submitted the patch). >>>>> >>>>> However, the tablet mode switch can be unreliable. Randomly, switch >>>>> events stop being reported and SW_TABLET_MODE will by stuck at 1 or 0, >>>>> which I have tested by running evtest while flipping the device to and >>>>> from tablet mode. This is fixed after a reboot, or a suspend followed by >>>>> unloading and reloading the intel-vbtn module. It can also sometimes be >>>>> the case that upon resume, SW_TABLET_MODE does not reflect the actual >>>>> state of the device, which is fixed by physically flipping the screen >>>>> back and forth to update the state. >>>>> >>>>> Because of these issues, I think this model should be removed from the >>>>> allow list, unless more investigation should be done. >>>> Hi Arnold, >>>> >>>> It's been a long time since you submitted the patch. Did those issues >>>> not occur during that time? >>>> Have you tried updating the BIOS to see if it helps? >>>> >>>> From your description, I think calling VBDL might reset the status. >>>> You might want to try it below. >>>> >>>> diff --git a/drivers/platform/x86/intel/vbtn.c >>>> b/drivers/platform/x86/intel/vbtn.c >>>> index 6fa1735ad7a49..681650f52ff22 100644 >>>> --- a/drivers/platform/x86/intel/vbtn.c >>>> +++ b/drivers/platform/x86/intel/vbtn.c >>>> @@ -198,6 +198,8 @@ static void notify_handler(acpi_handle handle, u32 >>>> event, void *context) >>>> autorelease = val && (!ke_rel || ke_rel->type == KE_IGNORE); >>>> >>>> sparse_keymap_report_event(input_dev, event, val, autorelease); >>>> + >>>> + acpi_evaluate_object(handle, "VBDL", NULL, NULL); >>>> } >>>> >>>> /* >>>> >>>>> >>>>> Thanks, >>>>> Arnold >>> >
