From: Hans de Goede <hdegoede@redhat.com>
To: Arnold Gozum <arngozum@gmail.com>, AceLan Kao <acelan.kao@canonical.com>
Cc: platform-driver-x86@vger.kernel.org
Subject: Re: [Bug Report] intel/vbtn: Dell Inspiron 7352 has unreliable tablet-mode switch
Date: Sun, 3 Dec 2023 16:41:22 +0100 [thread overview]
Message-ID: <b9bdfcbf-e263-42f9-9ddb-c7101348b18e@redhat.com> (raw)
In-Reply-To: <674140cc-fb03-4751-9bdf-13e86a6d39cc@redhat.com>
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@gmail.com> 於 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
>>
next prev parent reply other threads:[~2023-12-03 15:41 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-18 0:53 [Bug Report] intel/vbtn: Dell Inspiron 7352 has unreliable tablet-mode switch Arnold Gozum
2023-10-18 2:05 ` AceLan Kao
2023-10-29 19:52 ` Arnold Gozum
2023-11-20 14:18 ` Hans de Goede
2023-12-03 15:41 ` Hans de Goede [this message]
2023-12-04 2:43 ` Arnold Gozum
2023-12-04 15:07 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b9bdfcbf-e263-42f9-9ddb-c7101348b18e@redhat.com \
--to=hdegoede@redhat.com \
--cc=acelan.kao@canonical.com \
--cc=arngozum@gmail.com \
--cc=platform-driver-x86@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox