Re: [PATCH 1/7] platform/x86: fujitsu-laptop: do not use kfifo for storing hotkey scancodes
From: Darren Hart
Date: Fri Jun 23 2017 - 01:54:39 EST
On Fri, Jun 23, 2017 at 09:44:58AM +0930, Jonathan Woithe wrote:
> On Thu, Jun 22, 2017 at 04:58:09PM -0700, Darren Hart wrote:
> > On Thu, Jun 22, 2017 at 10:46:19PM +0200, Micha?? K??pie?? wrote:
> > > > The events seen by userspace with the original code would be "A-press",
> > > > "B-press", "A-release", "B-release". With the revised code the order of the
> > > > release events would be reversed compared to the previous behaviour. That
> > > > is, unless I've misunderstood how sparse_keymap_report_event() works.
> > >
> > > All you wrote above is correct and this patch does change the order of
> > > release events sent to userspace when multiple hotkeys are pressed
> > > simultaneously. The question is: is it relevant for any practical
> > > scenario?
> > >
> > > Anyway, I find this matter to be of secondary importance. The primary
> > > objective of this patch is to get rid of the kfifo. If anyone has
> > > strong feelings about the change in event ordering, I will be happy to
> > > revert to FIFO in v2.
> > This all looks reasonable to me, I don't see anything requiring a respin.
> I agree it is of seconary importance. To me, using LIFO release order is
> counter-intuitive, but it's the sort of question that if put to 100 people
> you'll get a 50/50 split of opinions.
> Especially since the whole "multiple buttons held at once" scenario is
> rather unusual we can go with switching the order if others don't see a
> problem with the behavioural change.
Yes. If anyone notices the implementation difference, I'll be rather surprised.
If they do, we can convert back to FIFO as you say.
VMware Open Source Technology Center