Re: [PATCH 0/3] dell-wmi: Don't send unneeded keypresses

[Gabriele Mazzotta]

On Saturday 20 December 2014 08:16:54 Darren Hart wrote:
> On Sat, Dec 20, 2014 at 04:11:08PM +0100, Pavel Machek wrote:
> > Hi!
> > 
> > > > > Ok, I agree that it is subjective how serious it is...
> > > > > Just to remind that patch fixing problem described in
> > > > > 
> > > > > http://www.spinics.net/lists/platform-driver-x86/msg05922.ht
> > > > > ml
> > > > > http://www.spinics.net/lists/platform-driver-x86/msg05924.h
> > > > > tml
> > > > 
> > > > I don't have any objection to sending this back to stable.
> > > > Stable is for fixing REAL bugs, as opposed to theorhetical
> > > > races, etc. This is a "real" bug.
> > > > 
> > > > As to not chaning behavior, if it's OK for mainline, it's OK
> > > > for stable. At least that is my understanding of it. Folks
> > > > are free to verify with Greg if they disagree.
> > > 
> > > Darren, so how you decided? Now when patches are in linus tree, 
> > > are you going to send them to stable tree?
> > 
> > Please don't. -stable is for serious mainline bugs people are actually
> > hitting. Null pointer dereference counts, if people actually hit
> > it. This is more behaviour change, and yes, the new behaviour is
> > better, but it is really different class.
> 
> In this case I agree with Pavel. While the patches are small enough, fix one
> thing each, etc, it isn't clear from the description exactly how these patches
> affect users.
> 
> If you can articulate how they are "real bugs that bother people" (see
> stable_kernel_rules.txt) we can reconsider. I should have pushed for better
> commit messages on these it appears as this should be obvious from those, but it
> isn't - at least not to me at 8:15am ;-)

The problem is that userspace programs responds to those keypresses when
they shouldn't.

In case of KEY_KBDILLUMTOGGLE, the illumination level is changed by the
BIOS, so if the keypress is reported, userspace programs will try to
toggle the keyboard illumination after the BIOS changed the level.
This is even more problematic if you consider that there could be
multiple illumination levels that are not taken into account if a
KEY_KBDILLUMTOGGLE is sent. Userspace will simply turn ON/OFF the
illumination, interfering with the BIOS.
This is shouldn't be a major problem since dell-laptop can control the
keyboard illumination only now and I can't see what userspace
application can misbehave without this change.

In the case of KEY_WLAN/KEY_RFKILL, the BIOS already takes care of
everything when the key is pressed, so sending keypresses as if
userspace programs have to do something is wrong. If for instance the
WiFi rfkill is soft blocked and I press the Fn key twice, I want it
to be soft blocked at the end. However, this is not the case.

Sorry for the brief commit messages.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/