Hey folks,
Commit 30323fb6d552c41997baca5292bf7001366cab57 (Support tablet mode
switch) causes the keyboard on my XPS 13 to stop working. This
particular model has a touch screen (which I've disabled in the BIOS),
but isn't a 2-in-1 with a tablet mode. My guess is it's being put in
tablet mode and that's disabling the keyboard? In any case, I'm happy
to test fixes and provide any necessary information.
Regards,
Jeremy
On gioved? 22 febbraio 2018 06:14:07 CET Jeremy Cline wrote:
> Hey folks,
>
> Commit 30323fb6d552c41997baca5292bf7001366cab57 (Support tablet mode
> switch) causes the keyboard on my XPS 13 to stop working. This
> particular model has a touch screen (which I've disabled in the BIOS),
> but isn't a 2-in-1 with a tablet mode. My guess is it's being put in
> tablet mode and that's disabling the keyboard? In any case, I'm happy
> to test fixes and provide any necessary information.
30323fb6d552c41997baca5292bf7001366cab57 initializes the switch to the correct
state, in theory, it seems VGBS() is returning the wrong thing? could it
report it has the switch and in a closed state even if it doesn't have it?
also seems device specific, on my inspiron6352 if i go in teblet mode the
keyboard keeps working until i fold it completely (which i don't know/don't
think is something detectable at all from the software side)
can you test with the command evtest (if an external keyboard works, or via
ssh)?, then looking at the state of the intel virtual button driver it should
show you the current state of the switch
--
Marco Martin
On 02/22/2018 05:21 AM, Marco Martin wrote:
> On giovedì 22 febbraio 2018 06:14:07 CET Jeremy Cline wrote:
>> Hey folks,
>>
>> Commit 30323fb6d552c41997baca5292bf7001366cab57 (Support tablet mode
>> switch) causes the keyboard on my XPS 13 to stop working. This
>> particular model has a touch screen (which I've disabled in the BIOS),
>> but isn't a 2-in-1 with a tablet mode. My guess is it's being put in
>> tablet mode and that's disabling the keyboard? In any case, I'm happy
>> to test fixes and provide any necessary information.
>
> 30323fb6d552c41997baca5292bf7001366cab57 initializes the switch to the correct
> state, in theory, it seems VGBS() is returning the wrong thing? could it
> report it has the switch and in a closed state even if it doesn't have it?
> also seems device specific, on my inspiron6352 if i go in teblet mode the
> keyboard keeps working until i fold it completely (which i don't know/don't
> think is something detectable at all from the software side)
>
> can you test with the command evtest (if an external keyboard works, or via
> ssh)?, then looking at the state of the intel virtual button driver it should
> show you the current state of the switch
>
Hi,
Here's the evtest output for the virtual button driver:
Input driver version is 1.0.1
Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
Input device name: "Intel Virtual Button driver"
Supported events:
Event type 0 (EV_SYN)
Event type 1 (EV_KEY)
Event code 114 (KEY_VOLUMEDOWN)
Event code 115 (KEY_VOLUMEUP)
Event code 116 (KEY_POWER)
Event code 125 (KEY_LEFTMETA)
Event code 240 (KEY_UNKNOWN)
Event code 561 (?)
Event type 4 (EV_MSC)
Event code 4 (MSC_SCAN)
Event type 5 (EV_SW)
Event code 1 (SW_TABLET_MODE) state 1
Properties:
Testing ... (interrupt to exit)
Regards,
Jeremy
On Thu, Feb 22, 2018 at 3:08 PM, Jeremy Cline <[email protected]> wrote:
> Input driver version is 1.0.1
> Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
> Input device name: "Intel Virtual Button driver"
> Supported events:
> Event type 0 (EV_SYN)
> Event type 1 (EV_KEY)
> Event code 114 (KEY_VOLUMEDOWN)
> Event code 115 (KEY_VOLUMEUP)
> Event code 116 (KEY_POWER)
> Event code 125 (KEY_LEFTMETA)
> Event code 240 (KEY_UNKNOWN)
> Event code 561 (?)
> Event type 4 (EV_MSC)
> Event code 4 (MSC_SCAN)
> Event type 5 (EV_SW)
> Event code 1 (SW_TABLET_MODE) state 1
> Properties:
> Testing ... (interrupt to exit)
Indeed, it's thinking a switch exists and that is on, which is wrong,
then i guess VGBS() reports a wrong status..
Mario, do you have any ideas about that?
--
Marco Martin
> -----Original Message-----
> From: Marco Martin [mailto:[email protected]]
> Sent: Thursday, February 22, 2018 9:16 AM
> To: Jeremy Cline <[email protected]>
> Cc: Limonciello, Mario <[email protected]>; Pali Rohár
> <[email protected]>; Andy Shevchenko <[email protected]>;
> Matthew Garrett <[email protected]>; Darren Hart <[email protected]>;
> Platform Driver <[email protected]>; Linux Kernel Mailing List
> <[email protected]>
> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>
> On Thu, Feb 22, 2018 at 3:08 PM, Jeremy Cline <[email protected]> wrote:
> > Input driver version is 1.0.1
> > Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
> > Input device name: "Intel Virtual Button driver"
> > Supported events:
> > Event type 0 (EV_SYN)
> > Event type 1 (EV_KEY)
> > Event code 114 (KEY_VOLUMEDOWN)
> > Event code 115 (KEY_VOLUMEUP)
> > Event code 116 (KEY_POWER)
> > Event code 125 (KEY_LEFTMETA)
> > Event code 240 (KEY_UNKNOWN)
> > Event code 561 (?)
> > Event type 4 (EV_MSC)
> > Event code 4 (MSC_SCAN)
> > Event type 5 (EV_SW)
> > Event code 1 (SW_TABLET_MODE) state 1
> > Properties:
> > Testing ... (interrupt to exit)
>
> Indeed, it's thinking a switch exists and that is on, which is wrong,
> then i guess VGBS() reports a wrong status..
> Mario, do you have any ideas about that?
>
> --
> Marco Martin
I guess that means we got this wrong and the patch should be reverted
until we figure this out.
Jeremy,
Can you please confirm what BIOS version you are on?
Also Is this a 9360 with 7th or 8th gen Intel CPU?
I'll see if I can find out anything more relative to this.
On 02/22/2018 10:21 AM, [email protected] wrote:> I guess that
means we got this wrong and the patch should be reverted
> until we figure this out.
>
> Jeremy,
>
> Can you please confirm what BIOS version you are on?
> Also Is this a 9360 with 7th or 8th gen Intel CPU?
Hi Mario,
I've got BIOS version 2.5.0 with the 7th gen Intel CPU.
Regards,
Jeremy
> -----Original Message-----
> From: Jeremy Cline [mailto:[email protected]]
> Sent: Thursday, February 22, 2018 9:59 AM
> To: Limonciello, Mario <[email protected]>; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; platform-driver-
> [email protected]; [email protected]
> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>
> On 02/22/2018 10:21 AM, [email protected] wrote:> I guess that
> means we got this wrong and the patch should be reverted
> > until we figure this out.
> >
> > Jeremy,
> >
> > Can you please confirm what BIOS version you are on?
> > Also Is this a 9360 with 7th or 8th gen Intel CPU?
>
> Hi Mario,
>
> I've got BIOS version 2.5.0 with the 7th gen Intel CPU.
>
>
> Regards,
> Jeremy
Jeremy,
Thanks. Do you have any of the Dell docks (TB16/WD15)? If so are you connected to any dock
when reproducing this problem?
Thanks,
On 02/22/2018 11:14 AM, [email protected] wrote:
>> -----Original Message-----
>> From: Jeremy Cline [mailto:[email protected]]
>> Sent: Thursday, February 22, 2018 9:59 AM
>> To: Limonciello, Mario <[email protected]>; [email protected]
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected]; platform-driver-
>> [email protected]; [email protected]
>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>>
>> On 02/22/2018 10:21 AM, [email protected] wrote:> I guess that
>> means we got this wrong and the patch should be reverted
>>> until we figure this out.
>>>
>>> Jeremy,
>>>
>>> Can you please confirm what BIOS version you are on?
>>> Also Is this a 9360 with 7th or 8th gen Intel CPU?
>>
>> Hi Mario,
>>
>> I've got BIOS version 2.5.0 with the 7th gen Intel CPU.
>>
>>
>> Regards,
>> Jeremy
>
> Jeremy,
>
> Thanks. Do you have any of the Dell docks (TB16/WD15)? If so are you connected to any dock
> when reproducing this problem?
Mario,
I do have a TB16. I can reproduce this whether or not I'm connected to
the dock, though.
Regards,
Jeremy
On Thu, Feb 22, 2018 at 03:21:45PM +0000, [email protected] wrote:
> > -----Original Message-----
> > From: Marco Martin [mailto:[email protected]]
> > Sent: Thursday, February 22, 2018 9:16 AM
> > To: Jeremy Cline <[email protected]>
> > Cc: Limonciello, Mario <[email protected]>; Pali Roh?r
> > <[email protected]>; Andy Shevchenko <[email protected]>;
> > Matthew Garrett <[email protected]>; Darren Hart <[email protected]>;
> > Platform Driver <[email protected]>; Linux Kernel Mailing List
> > <[email protected]>
> > Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> >
> > On Thu, Feb 22, 2018 at 3:08 PM, Jeremy Cline <[email protected]> wrote:
> > > Input driver version is 1.0.1
> > > Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
> > > Input device name: "Intel Virtual Button driver"
> > > Supported events:
> > > Event type 0 (EV_SYN)
> > > Event type 1 (EV_KEY)
> > > Event code 114 (KEY_VOLUMEDOWN)
> > > Event code 115 (KEY_VOLUMEUP)
> > > Event code 116 (KEY_POWER)
> > > Event code 125 (KEY_LEFTMETA)
> > > Event code 240 (KEY_UNKNOWN)
> > > Event code 561 (?)
> > > Event type 4 (EV_MSC)
> > > Event code 4 (MSC_SCAN)
> > > Event type 5 (EV_SW)
> > > Event code 1 (SW_TABLET_MODE) state 1
> > > Properties:
> > > Testing ... (interrupt to exit)
> >
> > Indeed, it's thinking a switch exists and that is on, which is wrong,
> > then i guess VGBS() reports a wrong status..
> > Mario, do you have any ideas about that?
> >
> > --
> > Marco Martin
>
> I guess that means we got this wrong and the patch should be reverted
> until we figure this out.
>
> Jeremy,
>
> Can you please confirm what BIOS version you are on?
> Also Is this a 9360 with 7th or 8th gen Intel CPU?
>
> I'll see if I can find out anything more relative to this.
Watching closely.
Mario, do you want me to revert immediately, or wait until you've had a couple
rounds of Q&A here?
--
Darren Hart
VMware Open Source Technology Center
> -----Original Message-----
> From: [email protected] [mailto:platform-driver-x86-
> [email protected]] On Behalf Of Jeremy Cline
> Sent: Thursday, February 22, 2018 10:17 AM
> To: Limonciello, Mario <[email protected]>; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; platform-driver-
> [email protected]; [email protected]
> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>
> On 02/22/2018 11:14 AM, [email protected] wrote:
> >> -----Original Message-----
> >> From: Jeremy Cline [mailto:[email protected]]
> >> Sent: Thursday, February 22, 2018 9:59 AM
> >> To: Limonciello, Mario <[email protected]>; [email protected]
> >> Cc: [email protected]; [email protected];
> >> [email protected]; [email protected]; platform-driver-
> >> [email protected]; [email protected]
> >> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> >>
> >> On 02/22/2018 10:21 AM, [email protected] wrote:> I guess that
> >> means we got this wrong and the patch should be reverted
> >>> until we figure this out.
> >>>
> >>> Jeremy,
> >>>
> >>> Can you please confirm what BIOS version you are on?
> >>> Also Is this a 9360 with 7th or 8th gen Intel CPU?
> >>
> >> Hi Mario,
> >>
> >> I've got BIOS version 2.5.0 with the 7th gen Intel CPU.
> >>
> >>
> >> Regards,
> >> Jeremy
> >
> > Jeremy,
> >
> > Thanks. Do you have any of the Dell docks (TB16/WD15)? If so are you connected
> to any dock
> > when reproducing this problem?
>
> Mario,
>
> I do have a TB16. I can reproduce this whether or not I'm connected to
> the dock, though.
>
>
> Regards,
> Jeremy
Jeremy,
Can you try booting up from a cold boot with it connected to see if it still happens?
> -----Original Message-----
> From: [email protected] [mailto:platform-driver-x86-
> [email protected]] On Behalf Of Darren Hart
> Sent: Thursday, February 22, 2018 10:19 AM
> To: Limonciello, Mario <[email protected]>
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]; platform-driver-
> [email protected]; [email protected]
> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>
> On Thu, Feb 22, 2018 at 03:21:45PM +0000, [email protected] wrote:
> > > -----Original Message-----
> > > From: Marco Martin [mailto:[email protected]]
> > > Sent: Thursday, February 22, 2018 9:16 AM
> > > To: Jeremy Cline <[email protected]>
> > > Cc: Limonciello, Mario <[email protected]>; Pali Roh?r
> > > <[email protected]>; Andy Shevchenko
> <[email protected]>;
> > > Matthew Garrett <[email protected]>; Darren Hart
> <[email protected]>;
> > > Platform Driver <[email protected]>; Linux Kernel Mailing
> List
> > > <[email protected]>
> > > Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> > >
> > > On Thu, Feb 22, 2018 at 3:08 PM, Jeremy Cline <[email protected]> wrote:
> > > > Input driver version is 1.0.1
> > > > Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
> > > > Input device name: "Intel Virtual Button driver"
> > > > Supported events:
> > > > Event type 0 (EV_SYN)
> > > > Event type 1 (EV_KEY)
> > > > Event code 114 (KEY_VOLUMEDOWN)
> > > > Event code 115 (KEY_VOLUMEUP)
> > > > Event code 116 (KEY_POWER)
> > > > Event code 125 (KEY_LEFTMETA)
> > > > Event code 240 (KEY_UNKNOWN)
> > > > Event code 561 (?)
> > > > Event type 4 (EV_MSC)
> > > > Event code 4 (MSC_SCAN)
> > > > Event type 5 (EV_SW)
> > > > Event code 1 (SW_TABLET_MODE) state 1
> > > > Properties:
> > > > Testing ... (interrupt to exit)
> > >
> > > Indeed, it's thinking a switch exists and that is on, which is wrong,
> > > then i guess VGBS() reports a wrong status..
> > > Mario, do you have any ideas about that?
> > >
> > > --
> > > Marco Martin
> >
> > I guess that means we got this wrong and the patch should be reverted
> > until we figure this out.
> >
> > Jeremy,
> >
> > Can you please confirm what BIOS version you are on?
> > Also Is this a 9360 with 7th or 8th gen Intel CPU?
> >
> > I'll see if I can find out anything more relative to this.
>
> Watching closely.
>
> Mario, do you want me to revert immediately, or wait until you've had a couple
> rounds of Q&A here?
>
> --
Darren,
Let's hold off until we've discussed a little more. Jeremy is responsive and we might
get to the bottom quickly.
Btw you have a 9360 on hand still right? Can you see if you can reproduce this problem too?
Thanks,
On Thu, Feb 22, 2018 at 04:28:57PM +0000, [email protected] wrote:
> > -----Original Message-----
> > From: [email protected] [mailto:platform-driver-x86-
> > [email protected]] On Behalf Of Darren Hart
> > Sent: Thursday, February 22, 2018 10:19 AM
> > To: Limonciello, Mario <[email protected]>
> > Cc: [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; platform-driver-
> > [email protected]; [email protected]
> > Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> >
> > On Thu, Feb 22, 2018 at 03:21:45PM +0000, [email protected] wrote:
> > > > -----Original Message-----
> > > > From: Marco Martin [mailto:[email protected]]
> > > > Sent: Thursday, February 22, 2018 9:16 AM
> > > > To: Jeremy Cline <[email protected]>
> > > > Cc: Limonciello, Mario <[email protected]>; Pali Roh?r
> > > > <[email protected]>; Andy Shevchenko
> > <[email protected]>;
> > > > Matthew Garrett <[email protected]>; Darren Hart
> > <[email protected]>;
> > > > Platform Driver <[email protected]>; Linux Kernel Mailing
> > List
> > > > <[email protected]>
> > > > Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> > > >
> > > > On Thu, Feb 22, 2018 at 3:08 PM, Jeremy Cline <[email protected]> wrote:
> > > > > Input driver version is 1.0.1
> > > > > Input device ID: bus 0x19 vendor 0x0 product 0x0 version 0x0
> > > > > Input device name: "Intel Virtual Button driver"
> > > > > Supported events:
> > > > > Event type 0 (EV_SYN)
> > > > > Event type 1 (EV_KEY)
> > > > > Event code 114 (KEY_VOLUMEDOWN)
> > > > > Event code 115 (KEY_VOLUMEUP)
> > > > > Event code 116 (KEY_POWER)
> > > > > Event code 125 (KEY_LEFTMETA)
> > > > > Event code 240 (KEY_UNKNOWN)
> > > > > Event code 561 (?)
> > > > > Event type 4 (EV_MSC)
> > > > > Event code 4 (MSC_SCAN)
> > > > > Event type 5 (EV_SW)
> > > > > Event code 1 (SW_TABLET_MODE) state 1
> > > > > Properties:
> > > > > Testing ... (interrupt to exit)
> > > >
> > > > Indeed, it's thinking a switch exists and that is on, which is wrong,
> > > > then i guess VGBS() reports a wrong status..
> > > > Mario, do you have any ideas about that?
> > > >
> > > > --
> > > > Marco Martin
> > >
> > > I guess that means we got this wrong and the patch should be reverted
> > > until we figure this out.
> > >
> > > Jeremy,
> > >
> > > Can you please confirm what BIOS version you are on?
> > > Also Is this a 9360 with 7th or 8th gen Intel CPU?
> > >
> > > I'll see if I can find out anything more relative to this.
> >
> > Watching closely.
> >
> > Mario, do you want me to revert immediately, or wait until you've had a couple
> > rounds of Q&A here?
> >
> > --
>
> Darren,
>
> Let's hold off until we've discussed a little more. Jeremy is responsive and we might
> get to the bottom quickly.
>
> Btw you have a 9360 on hand still right? Can you see if you can reproduce this problem too?
>
I'm planning on it, yup.
--
Darren Hart
VMware Open Source Technology Center
On 02/22/2018 11:17 AM, [email protected] wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:platform-driver-x86-
>> [email protected]] On Behalf Of Jeremy Cline
>> Sent: Thursday, February 22, 2018 10:17 AM
>> To: Limonciello, Mario <[email protected]>; [email protected]
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected]; platform-driver-
>> [email protected]; [email protected]
>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>>
>> On 02/22/2018 11:14 AM, [email protected] wrote:
>>>> -----Original Message-----
>>>> From: Jeremy Cline [mailto:[email protected]]
>>>> Sent: Thursday, February 22, 2018 9:59 AM
>>>> To: Limonciello, Mario <[email protected]>; [email protected]
>>>> Cc: [email protected]; [email protected];
>>>> [email protected]; [email protected]; platform-driver-
>>>> [email protected]; [email protected]
>>>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>>>>
>>>> On 02/22/2018 10:21 AM, [email protected] wrote:> I guess that
>>>> means we got this wrong and the patch should be reverted
>>>>> until we figure this out.
>>>>>
>>>>> Jeremy,
>>>>>
>>>>> Can you please confirm what BIOS version you are on?
>>>>> Also Is this a 9360 with 7th or 8th gen Intel CPU?
>>>>
>>>> Hi Mario,
>>>>
>>>> I've got BIOS version 2.5.0 with the 7th gen Intel CPU.
>>>>
>>>>
>>>> Regards,
>>>> Jeremy
>>>
>>> Jeremy,
>>>
>>> Thanks. Do you have any of the Dell docks (TB16/WD15)? If so are you connected
>> to any dock
>>> when reproducing this problem?
>>
>> Mario,
>>
>> I do have a TB16. I can reproduce this whether or not I'm connected to
>> the dock, though.
>>
>>
>> Regards,
>> Jeremy
>
> Jeremy,
>
> Can you try booting up from a cold boot with it connected to see if it still happens?
>
Mario,
Yup, it still happens from a cold boot when connected to the dock.
> -----Original Message-----
> From: [email protected] [mailto:platform-driver-x86-
> [email protected]] On Behalf Of Jeremy Cline
> Sent: Thursday, February 22, 2018 10:42 AM
> To: Limonciello, Mario <[email protected]>; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; platform-driver-
> [email protected]; [email protected]
> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>
> On 02/22/2018 11:17 AM, [email protected] wrote:
> >> -----Original Message-----
> >> From: [email protected] [mailto:platform-driver-x86-
> >> [email protected]] On Behalf Of Jeremy Cline
> >> Sent: Thursday, February 22, 2018 10:17 AM
> >> To: Limonciello, Mario <[email protected]>; [email protected]
> >> Cc: [email protected]; [email protected];
> >> [email protected]; [email protected]; platform-driver-
> >> [email protected]; [email protected]
> >> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> >>
> >> On 02/22/2018 11:14 AM, [email protected] wrote:
> >>>> -----Original Message-----
> >>>> From: Jeremy Cline [mailto:[email protected]]
> >>>> Sent: Thursday, February 22, 2018 9:59 AM
> >>>> To: Limonciello, Mario <[email protected]>; [email protected]
> >>>> Cc: [email protected]; [email protected];
> >>>> [email protected]; [email protected]; platform-driver-
> >>>> [email protected]; [email protected]
> >>>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> >>>>
> >>>> On 02/22/2018 10:21 AM, [email protected] wrote:> I guess that
> >>>> means we got this wrong and the patch should be reverted
> >>>>> until we figure this out.
> >>>>>
> >>>>> Jeremy,
> >>>>>
> >>>>> Can you please confirm what BIOS version you are on?
> >>>>> Also Is this a 9360 with 7th or 8th gen Intel CPU?
> >>>>
> >>>> Hi Mario,
> >>>>
> >>>> I've got BIOS version 2.5.0 with the 7th gen Intel CPU.
> >>>>
> >>>>
> >>>> Regards,
> >>>> Jeremy
> >>>
> >>> Jeremy,
> >>>
> >>> Thanks. Do you have any of the Dell docks (TB16/WD15)? If so are you
> connected
> >> to any dock
> >>> when reproducing this problem?
> >>
> >> Mario,
> >>
> >> I do have a TB16. I can reproduce this whether or not I'm connected to
> >> the dock, though.
> >>
> >>
> >> Regards,
> >> Jeremy
> >
> > Jeremy,
> >
> > Can you try booting up from a cold boot with it connected to see if it still
> happens?
> >
>
> Mario,
>
> Yup, it still happens from a cold boot when connected to the dock.
OK thanks for confirming. Here's what I've concluded:
* So looking through the ACPI tables on the 9360 it initializes that status
(slate vs laptop mode) bit to "slate" mode. The 9360 isn't a 2-in1- so that
seems wrong to me, but that's what it does.
It only gets updated based on dock status.
The 9365 (which is a 2 in 1) however seems to initialize the status properly.
So that's an impasse of what to do.
It's not clear to me what is really happening:
a) We're missing something else in this driver (eg something else that
indicates whether to trust VGBS output)
b) Mis-interpreting the results from it (we shouldn't report the switch for
tablet mode based on what we do)
c) 9360 has a BIOS bug (seems unlikely since Windows doesn't freak out and
show virtual keyboard at wrong time)
I'm leaning on it's probably <a>.
We should check for tablet mode should only be run if chassis type
matches 2-in-1 (chassis type 0x1F).
I believe that should fix the problem on the 9360, let it continue to work on
the 9365 (and other 2-in-1's).
Can you guys please test this? If that works I'll split up the routine and submit
it.
diff --git a/drivers/platform/x86/intel-vbtn.c b/drivers/platform/x86/intel-vbtn.c
index b703d6f..07bc489 100644
--- a/drivers/platform/x86/intel-vbtn.c
+++ b/drivers/platform/x86/intel-vbtn.c
@@ -7,6 +7,7 @@
*/
#include <linux/acpi.h>
+#include <linux/dmi.h>
#include <linux/input.h>
#include <linux/input/sparse-keymap.h>
#include <linux/kernel.h>
@@ -102,6 +103,7 @@ static int intel_vbtn_probe(struct platform_device *device)
struct acpi_buffer vgbs_output = { ACPI_ALLOCATE_BUFFER, NULL };
acpi_handle handle = ACPI_HANDLE(&device->dev);
struct intel_vbtn_priv *priv;
+ const char *chassis_type;
acpi_status status;
int err;
@@ -123,22 +125,24 @@ static int intel_vbtn_probe(struct platform_device *device)
}
/*
- * VGBS being present and returning something means we have
- * a tablet mode switch.
+ * Running on 2-in-1 chassis, VGBS being present and
+ * returning something means we have a tablet mode switch.
*/
- status = acpi_evaluate_object(handle, "VGBS", NULL, &vgbs_output);
- if (ACPI_SUCCESS(status)) {
- union acpi_object *obj = vgbs_output.pointer;
+ chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
+ if (chassis_type && strcmp(chassis_type, "31")) {
+ status = acpi_evaluate_object(handle, "VGBS", NULL, &vgbs_output);
+ if (ACPI_SUCCESS(status)) {
+ union acpi_object *obj = vgbs_output.pointer;
- if (obj && obj->type == ACPI_TYPE_INTEGER) {
- int m = !(obj->integer.value & TABLET_MODE_FLAG);
+ if (obj && obj->type == ACPI_TYPE_INTEGER) {
+ int m = !(obj->integer.value & TABLET_MODE_FLAG);
- input_report_switch(priv->input_dev, SW_TABLET_MODE, m);
+ input_report_switch(priv->input_dev, SW_TABLET_MODE, m);
+ }
}
+ kfree(vgbs_output.pointer);
}
- kfree(vgbs_output.pointer);
-
status = acpi_install_notify_handler(handle,
ACPI_DEVICE_NOTIFY,
notify_handler,
On 02/22/2018 12:05 PM, [email protected] wrote:
>> -----Original Message-----
>> From: [email protected] [mailto:platform-driver-x86-
>> [email protected]] On Behalf Of Jeremy Cline
>> Sent: Thursday, February 22, 2018 10:42 AM
>> To: Limonciello, Mario <[email protected]>; [email protected]
>> Cc: [email protected]; [email protected];
>> [email protected]; [email protected]; platform-driver-
>> [email protected]; [email protected]
>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>>
>> On 02/22/2018 11:17 AM, [email protected] wrote:
>>>> -----Original Message-----
>>>> From: [email protected] [mailto:platform-driver-x86-
>>>> [email protected]] On Behalf Of Jeremy Cline
>>>> Sent: Thursday, February 22, 2018 10:17 AM
>>>> To: Limonciello, Mario <[email protected]>; [email protected]
>>>> Cc: [email protected]; [email protected];
>>>> [email protected]; [email protected]; platform-driver-
>>>> [email protected]; [email protected]
>>>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>>>>
>>>> On 02/22/2018 11:14 AM, [email protected] wrote:
>>>>>> -----Original Message-----
>>>>>> From: Jeremy Cline [mailto:[email protected]]
>>>>>> Sent: Thursday, February 22, 2018 9:59 AM
>>>>>> To: Limonciello, Mario <[email protected]>; [email protected]
>>>>>> Cc: [email protected]; [email protected];
>>>>>> [email protected]; [email protected]; platform-driver-
>>>>>> [email protected]; [email protected]
>>>>>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>>>>>>
>>>>>> On 02/22/2018 10:21 AM, [email protected] wrote:> I guess that
>>>>>> means we got this wrong and the patch should be reverted
>>>>>>> until we figure this out.
>>>>>>>
>>>>>>> Jeremy,
>>>>>>>
>>>>>>> Can you please confirm what BIOS version you are on?
>>>>>>> Also Is this a 9360 with 7th or 8th gen Intel CPU?
>>>>>>
>>>>>> Hi Mario,
>>>>>>
>>>>>> I've got BIOS version 2.5.0 with the 7th gen Intel CPU.
>>>>>>
>>>>>>
>>>>>> Regards,
>>>>>> Jeremy
>>>>>
>>>>> Jeremy,
>>>>>
>>>>> Thanks. Do you have any of the Dell docks (TB16/WD15)? If so are you
>> connected
>>>> to any dock
>>>>> when reproducing this problem?
>>>>
>>>> Mario,
>>>>
>>>> I do have a TB16. I can reproduce this whether or not I'm connected to
>>>> the dock, though.
>>>>
>>>>
>>>> Regards,
>>>> Jeremy
>>>
>>> Jeremy,
>>>
>>> Can you try booting up from a cold boot with it connected to see if it still
>> happens?
>>>
>>
>> Mario,
>>
>> Yup, it still happens from a cold boot when connected to the dock.
>
> OK thanks for confirming. Here's what I've concluded:
>
> * So looking through the ACPI tables on the 9360 it initializes that status
> (slate vs laptop mode) bit to "slate" mode. The 9360 isn't a 2-in1- so that
> seems wrong to me, but that's what it does.
> It only gets updated based on dock status.
>
> The 9365 (which is a 2 in 1) however seems to initialize the status properly.
>
> So that's an impasse of what to do.
> It's not clear to me what is really happening:
> a) We're missing something else in this driver (eg something else that
> indicates whether to trust VGBS output)
>
> b) Mis-interpreting the results from it (we shouldn't report the switch for
> tablet mode based on what we do)
>
> c) 9360 has a BIOS bug (seems unlikely since Windows doesn't freak out and
> show virtual keyboard at wrong time)
>
> I'm leaning on it's probably <a>.
> We should check for tablet mode should only be run if chassis type
> matches 2-in-1 (chassis type 0x1F).
>
> I believe that should fix the problem on the 9360, let it continue to work on
> the 9365 (and other 2-in-1's).
>
> Can you guys please test this? If that works I'll split up the routine and submit
> it.
>
Hi Mario,
There's one small error in the patch, after I fixed it, it works.
Thanks!
> diff --git a/drivers/platform/x86/intel-vbtn.c b/drivers/platform/x86/intel-vbtn.c
> index b703d6f..07bc489 100644
> --- a/drivers/platform/x86/intel-vbtn.c
> +++ b/drivers/platform/x86/intel-vbtn.c
> @@ -7,6 +7,7 @@
> */
>
> #include <linux/acpi.h>
> +#include <linux/dmi.h>
> #include <linux/input.h>
> #include <linux/input/sparse-keymap.h>
> #include <linux/kernel.h>
> @@ -102,6 +103,7 @@ static int intel_vbtn_probe(struct platform_device *device)
> struct acpi_buffer vgbs_output = { ACPI_ALLOCATE_BUFFER, NULL };
> acpi_handle handle = ACPI_HANDLE(&device->dev);
> struct intel_vbtn_priv *priv;
> + const char *chassis_type;
> acpi_status status;
> int err;
>
> @@ -123,22 +125,24 @@ static int intel_vbtn_probe(struct platform_device *device)
> }
>
> /*
> - * VGBS being present and returning something means we have
> - * a tablet mode switch.
> + * Running on 2-in-1 chassis, VGBS being present and
> + * returning something means we have a tablet mode switch.
> */
> - status = acpi_evaluate_object(handle, "VGBS", NULL, &vgbs_output);
> - if (ACPI_SUCCESS(status)) {
> - union acpi_object *obj = vgbs_output.pointer;
> + chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
> + if (chassis_type && strcmp(chassis_type, "31")) {This should be "chassis_type && strcmp(chassis_type, "31") == 0" since
strcmp returns 0 for equality.
> + status = acpi_evaluate_object(handle, "VGBS", NULL, &vgbs_output);
> + if (ACPI_SUCCESS(status)) {
> + union acpi_object *obj = vgbs_output.pointer;
>
> - if (obj && obj->type == ACPI_TYPE_INTEGER) {
> - int m = !(obj->integer.value & TABLET_MODE_FLAG);
> + if (obj && obj->type == ACPI_TYPE_INTEGER) {
> + int m = !(obj->integer.value & TABLET_MODE_FLAG);
>
> - input_report_switch(priv->input_dev, SW_TABLET_MODE, m);
> + input_report_switch(priv->input_dev, SW_TABLET_MODE, m);
> + }
> }
> + kfree(vgbs_output.pointer);
> }
> - kfree(vgbs_output.pointer);
> -
> status = acpi_install_notify_handler(handle,
> ACPI_DEVICE_NOTIFY,
> notify_handler,
>
Regards,
Jeremy
On Thu, Feb 22, 2018 at 05:05:39PM +0000, [email protected] wrote:
...
> OK thanks for confirming. Here's what I've concluded:
>
> * So looking through the ACPI tables on the 9360 it initializes that status
> (slate vs laptop mode) bit to "slate" mode. The 9360 isn't a 2-in1- so that
> seems wrong to me, but that's what it does.
> It only gets updated based on dock status.
>
> The 9365 (which is a 2 in 1) however seems to initialize the status properly.
>
> So that's an impasse of what to do.
> It's not clear to me what is really happening:
> a) We're missing something else in this driver (eg something else that
> indicates whether to trust VGBS output)
>
> b) Mis-interpreting the results from it (we shouldn't report the switch for
> tablet mode based on what we do)
>
> c) 9360 has a BIOS bug (seems unlikely since Windows doesn't freak out and
> show virtual keyboard at wrong time)
>
> I'm leaning on it's probably <a>.
> We should check for tablet mode should only be run if chassis type
> matches 2-in-1 (chassis type 0x1F).
This sounds like a good approach to me.
> I believe that should fix the problem on the 9360, let it continue to work on
> the 9365 (and other 2-in-1's).
>
> Can you guys please test this? If that works I'll split up the routine and submit
> it.
Queueing this up as well.
--
Darren Hart
VMware Open Source Technology Center
> -----Original Message-----
> From: [email protected] [mailto:platform-driver-x86-
> [email protected]] On Behalf Of Jeremy Cline
> Sent: Thursday, February 22, 2018 1:45 PM
> To: Limonciello, Mario <[email protected]>; [email protected]
> Cc: [email protected]; [email protected];
> [email protected]; [email protected]; platform-driver-
> [email protected]; [email protected]
> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
>
> On 02/22/2018 12:05 PM, [email protected] wrote:
> >> -----Original Message-----
> >> From: [email protected] [mailto:platform-driver-x86-
> >> [email protected]] On Behalf Of Jeremy Cline
> >> Sent: Thursday, February 22, 2018 10:42 AM
> >> To: Limonciello, Mario <[email protected]>; [email protected]
> >> Cc: [email protected]; [email protected];
> >> [email protected]; [email protected]; platform-driver-
> >> [email protected]; [email protected]
> >> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> >>
> >> On 02/22/2018 11:17 AM, [email protected] wrote:
> >>>> -----Original Message-----
> >>>> From: [email protected] [mailto:platform-driver-
> x86-
> >>>> [email protected]] On Behalf Of Jeremy Cline
> >>>> Sent: Thursday, February 22, 2018 10:17 AM
> >>>> To: Limonciello, Mario <[email protected]>; [email protected]
> >>>> Cc: [email protected]; [email protected];
> >>>> [email protected]; [email protected]; platform-driver-
> >>>> [email protected]; [email protected]
> >>>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> >>>>
> >>>> On 02/22/2018 11:14 AM, [email protected] wrote:
> >>>>>> -----Original Message-----
> >>>>>> From: Jeremy Cline [mailto:[email protected]]
> >>>>>> Sent: Thursday, February 22, 2018 9:59 AM
> >>>>>> To: Limonciello, Mario <[email protected]>;
> [email protected]
> >>>>>> Cc: [email protected]; [email protected];
> >>>>>> [email protected]; [email protected]; platform-driver-
> >>>>>> [email protected]; [email protected]
> >>>>>> Subject: Re: Regression: Dell XPS 13 9360 keyboard no longer works
> >>>>>>
> >>>>>> On 02/22/2018 10:21 AM, [email protected] wrote:> I guess
> that
> >>>>>> means we got this wrong and the patch should be reverted
> >>>>>>> until we figure this out.
> >>>>>>>
> >>>>>>> Jeremy,
> >>>>>>>
> >>>>>>> Can you please confirm what BIOS version you are on?
> >>>>>>> Also Is this a 9360 with 7th or 8th gen Intel CPU?
> >>>>>>
> >>>>>> Hi Mario,
> >>>>>>
> >>>>>> I've got BIOS version 2.5.0 with the 7th gen Intel CPU.
> >>>>>>
> >>>>>>
> >>>>>> Regards,
> >>>>>> Jeremy
> >>>>>
> >>>>> Jeremy,
> >>>>>
> >>>>> Thanks. Do you have any of the Dell docks (TB16/WD15)? If so are you
> >> connected
> >>>> to any dock
> >>>>> when reproducing this problem?
> >>>>
> >>>> Mario,
> >>>>
> >>>> I do have a TB16. I can reproduce this whether or not I'm connected to
> >>>> the dock, though.
> >>>>
> >>>>
> >>>> Regards,
> >>>> Jeremy
> >>>
> >>> Jeremy,
> >>>
> >>> Can you try booting up from a cold boot with it connected to see if it still
> >> happens?
> >>>
> >>
> >> Mario,
> >>
> >> Yup, it still happens from a cold boot when connected to the dock.
> >
> > OK thanks for confirming. Here's what I've concluded:
> >
> > * So looking through the ACPI tables on the 9360 it initializes that status
> > (slate vs laptop mode) bit to "slate" mode. The 9360 isn't a 2-in1- so that
> > seems wrong to me, but that's what it does.
> > It only gets updated based on dock status.
> >
> > The 9365 (which is a 2 in 1) however seems to initialize the status properly.
> >
> > So that's an impasse of what to do.
> > It's not clear to me what is really happening:
> > a) We're missing something else in this driver (eg something else that
> > indicates whether to trust VGBS output)
> >
> > b) Mis-interpreting the results from it (we shouldn't report the switch for
> > tablet mode based on what we do)
> >
> > c) 9360 has a BIOS bug (seems unlikely since Windows doesn't freak out and
> > show virtual keyboard at wrong time)
> >
> > I'm leaning on it's probably <a>.
> > We should check for tablet mode should only be run if chassis type
> > matches 2-in-1 (chassis type 0x1F).
> >
> > I believe that should fix the problem on the 9360, let it continue to work on
> > the 9365 (and other 2-in-1's).
> >
> > Can you guys please test this? If that works I'll split up the routine and submit
> > it.
> >
>
> Hi Mario,
>
> There's one small error in the patch, after I fixed it, it works.
> Thanks!
Thanks, glad to hear. I sent it to the list separately with my cleanups and your
fix for strcmp.
If you can re-test with the cleaned up patch to add a Tested-By, that would
be great.
>
> > diff --git a/drivers/platform/x86/intel-vbtn.c b/drivers/platform/x86/intel-vbtn.c
> > index b703d6f..07bc489 100644
> > --- a/drivers/platform/x86/intel-vbtn.c
> > +++ b/drivers/platform/x86/intel-vbtn.c
> > @@ -7,6 +7,7 @@
> > */
> >
> > #include <linux/acpi.h>
> > +#include <linux/dmi.h>
> > #include <linux/input.h>
> > #include <linux/input/sparse-keymap.h>
> > #include <linux/kernel.h>
> > @@ -102,6 +103,7 @@ static int intel_vbtn_probe(struct platform_device
> *device)
> > struct acpi_buffer vgbs_output = { ACPI_ALLOCATE_BUFFER, NULL };
> > acpi_handle handle = ACPI_HANDLE(&device->dev);
> > struct intel_vbtn_priv *priv;
> > + const char *chassis_type;
> > acpi_status status;
> > int err;
> >
> > @@ -123,22 +125,24 @@ static int intel_vbtn_probe(struct platform_device
> *device)
> > }
> >
> > /*
> > - * VGBS being present and returning something means we have
> > - * a tablet mode switch.
> > + * Running on 2-in-1 chassis, VGBS being present and
> > + * returning something means we have a tablet mode switch.
> > */
> > - status = acpi_evaluate_object(handle, "VGBS", NULL, &vgbs_output);
> > - if (ACPI_SUCCESS(status)) {
> > - union acpi_object *obj = vgbs_output.pointer;
> > + chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE);
> > + if (chassis_type && strcmp(chassis_type, "31")) {This should be
> "chassis_type && strcmp(chassis_type, "31") == 0" since
> strcmp returns 0 for equality.
>
> > + status = acpi_evaluate_object(handle, "VGBS", NULL, &vgbs_output);
> > + if (ACPI_SUCCESS(status)) {
> > + union acpi_object *obj = vgbs_output.pointer;
> >
> > - if (obj && obj->type == ACPI_TYPE_INTEGER) {
> > - int m = !(obj->integer.value & TABLET_MODE_FLAG);
> > + if (obj && obj->type == ACPI_TYPE_INTEGER) {
> > + int m = !(obj->integer.value & TABLET_MODE_FLAG);
> >
> > - input_report_switch(priv->input_dev, SW_TABLET_MODE, m);
> > + input_report_switch(priv->input_dev, SW_TABLET_MODE, m);
> > + }
> > }
> > + kfree(vgbs_output.pointer);
> > }
> > - kfree(vgbs_output.pointer);
> > -
> > status = acpi_install_notify_handler(handle,
> > ACPI_DEVICE_NOTIFY,
> > notify_handler,
> >
>
> Regards,
> Jeremy