Re: [RFC PATCH 1/1] Input: gpio-keys: export gpio key information through sysfs

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

 



Sorry Dmitry, I'm new to the input subsystem, may be this is why I still
do not see any problem with introducing a nice and useful ioctl?

On Wed, 2009-11-11 at 00:19 -0800, Dmitry Torokhov wrote:
> > > I understand the appeal of working with the keycodes but what you are
> > > asking is not simply ignoring certain keypresses (that is easy, just
> > > ignore corresponding events in userspace), you want to prevent system
> > > from waking up. In other words you want to "control PM layer through
> > > input layer" and I believe this is wrong.
> > 
> > Err, this is really about disabling keys. 
> 
> If you want to stop delivery of certain keycodes to userspace then OK,
> an option to subscrbe to certain events only instead of getting all
> events from the device. But again, it will only work for that particular
> user only, not everyone.

Yes, this will work for some particular input devices only, those which
support the keys masking. What is wrong with this? We have the '-ENOTTY'
error code, which for ioctl's means "ioctl is not supported".

But no one prevents us from making this work for _every_ input device by
implementing a default ioctl handler in evdev.c, if needed. This handler
can mask certain keys in SW.

IOW:
   1. if my HW supports HW key masking, the evdev ioctl calls my
      handler, which is implemented in my driver.
   2. if my HW does not support this, the evdev ioctl masks the keys in
      SW.

We are interested in 1. And if later someone needs 2., he/she can very
easily implement that. But for now we can just return -ENOTTY (or
-EINVAL, which seems to be used in the input subsystem).

> > If we think about this in an
> > abstract way, you have an input device with many keys. And the device's
> > HW allows you to disable any of it's keys. When you disable the key, the
> > input device ignores it and does not generate any interrupt for it.
> 
> And the reason you want to stop interrupts?

The reason is that I want simply mute certain keys. This is the only
reason.

Now the question is _how_ I want to mute the key. My HW supports muting,
so I want to mute it in HW level, just because it is much better and
more efficient. Just because in this case I will not have any interrupt
and my device will wake up less.

-- 
Best Regards,
Artem Bityutskiy (Артём Битюцкий)

--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Media Devel]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [Linux Wireless Networking]     [Linux Omap]

  Powered by Linux