Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tuesday 21 June 2016 20:16:09 Mario_Limonciello@xxxxxxxx wrote:
> > -----Original Message-----
> > From: Darren Hart [mailto:dvhart@xxxxxxxxxxxxx]
> > Sent: Tuesday, June 21, 2016 1:06 PM
> > To: Pali Rohár <pali.rohar@xxxxxxxxx>
> > Cc: Gabriele Mazzotta <gabriele.mzt@xxxxxxxxx>; Andy Lutomirski
> > <luto@xxxxxxxxxx>; Alex Hung <alex.hung@xxxxxxxxxxxxx>; Matthew
> > Garrett <mjg59@xxxxxxxxxxxxx>; Michał Kępień <kernel@xxxxxxxxxx>;
> > Limonciello, Mario <Mario_Limonciello@xxxxxxxx>; platform-driver-
> > x86@xxxxxxxxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx
> > Subject: Re: [PATCH v3 0/4] dell-wmi: Changes in WMI event code
> > handling
> > 
> > On Thu, Jun 16, 2016 at 09:33:02AM +0200, Pali Rohár wrote:
> > > On Wednesday 15 June 2016 20:19:58 Darren Hart wrote:
> > > > On Wed, Jun 15, 2016 at 09:49:09PM +0200, Pali Rohár wrote:
> > > > > First patch describe problem about 0xe045 code. Second and
> > > > > third are
> > 
> > just
> > 
> > > > > cosmetic and last rework code which processing WMI events. It
> > > > > should
> > 
> > be
> > 
> > > > > properly tested on more Dell machines, to check that
> > > > > everything is still working correctly.
> > > > 
> > > > Is this "should be properly tested on more Dell machines" still
> > > > the case?
> > 
> > Are
> > 
> > > > you ready for this to go into linux-next?
> > > 
> > > Series should be OK, but I would like to see if someone else test
> > > this series... Gabriele, Alex or Andy? Do you have time?
> > 
> > Tested on a Dell XPS 13 2016 (9350). All hotkeys appear to work
> > without warning
> > messages. I didn't get anything out of Fn-F8 which has a picture of
> > a laptop and
> > white screen behind it. Not sure what that is supposed to do - if
> > it was meant to blank the screen, it did not, perhaps it is meant
> > to toggle screen outputs... will test that when I have access to
> > an external display.
> 
> That key is meant to toggle screen outputs.  I believe it's still
> done by the EC emitting <super> + p.  If your WM doesn't recognize
> that, it won't do much, but you can see in xev the key combinations.

I still do not understand this stupidity, pressing *one* key cause 
emitting two keys to OS and then OS needs to handle combinations of keys 
and acts on it correctly.... (like windows manager)

Is there some way to disable this insane nonsense activity of BIOS, 
firmware or whatever it is doing in HW to send *one* key scancode when 
pressing *one* key?

-- 
Pali Rohár
pali.rohar@xxxxxxxxx

Attachment: signature.asc
Description: This is a digitally signed message part.


[Index of Archives]     [Linux Kernel Development]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux