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

[Pavel Machek <pavel@ucw.cz>]

On Sat 2014-12-20 18:02:49, Pali Rohár wrote:
> 2014-12-20 17:28 GMT+01:00 Henrique de Moraes Holschuh <hmh@hmh.eng.br>:
> 
> > On Sat, 20 Dec 2014, Pavel Machek wrote:
> > > > > > 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.
> >
> > Sometimes the old behavior is something that is a major pain for users and
> > userspace.  In that case, where the new behavior fixes really annoying
> > usecase bugs, the fix belongs in -stable IMHO.
> >
> > Broken behavior hits, by definition, every user of the feature after all.
> >
> > --
> >   "One disk to rule them all, One disk to find them. One disk to bring
> >   them all and in the darkness grind them. In the Land of Redmond
> >   where the shadows lie." -- The Silicon Valley Tarot
> >   Henrique Holschuh
> >
> 
> Ok, I'm asking. It's up to you how you decide. Problem with keyboard
> illumination button is that BIOS change keyboard backlight plus it send
> keycode. So if you have userspace application which listening for
> illumination button and then do something with that event (e.g change
> keyboard backlight) you will get duplicate actions (or cyclic events, etc).
> But if you think that this change should not go to stable tree, its ok. I'm
> just ask how you decide...

Well, user report "keyboard illumination does not work in GNOME
3.14159 on Mandriva 1.732 and this patch fixes it" would certainly help.

But I'm afraid that Fedora 1.4142 already knows and expects those
duplicate events.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html