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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.