[PATCH] Input notifier support

[PATCH] Input notifier support

[Kyungmin Park]

Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.

So add input notifier and then use it at other frameworks such as led.
Of course, other input device can use this one.

Any commnets are welcome.

Thank you,
Kyungmin Park

Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
---
diff --git a/drivers/input/Makefile b/drivers/input/Makefile
index 4c9c745..99feb46 100644
--- a/drivers/input/Makefile
+++ b/drivers/input/Makefile
@@ -5,7 +5,7 @@
 # Each configuration option enables a list of files.
 
 obj-$(CONFIG_INPUT)		+= input-core.o
-input-core-objs := input.o input-compat.o ff-core.o
+input-core-objs := input.o input-compat.o ff-core.o input_notify.o
 
 obj-$(CONFIG_INPUT_FF_MEMLESS)	+= ff-memless.o
 obj-$(CONFIG_INPUT_POLLDEV)	+= input-polldev.o
diff --git a/drivers/input/input.c b/drivers/input/input.c
index 1730d73..7e96635 100644
--- a/drivers/input/input.c
+++ b/drivers/input/input.c
@@ -274,6 +274,8 @@ void input_event(struct input_dev *dev,
 		add_input_randomness(type, code, value);
 		input_handle_event(dev, type, code, value);
 		spin_unlock_irqrestore(&dev->event_lock, flags);
+		if (type == EV_KEY)
+			input_notifier_call_chain(value, &code);
 	}
 }
 EXPORT_SYMBOL(input_event);
diff --git a/drivers/input/input_notify.c b/drivers/input/input_notify.c
new file mode 100644
index 0000000..a89cfb6
--- /dev/null
+++ b/drivers/input/input_notify.c
@@ -0,0 +1,43 @@
+/*
+ * Input Notifier
+ *
+ * Copyright (C) 2009 Samsung Electronics
+ * Kyungmin Park <kyungmin.park@samsung.com>
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ */
+#include <linux/input.h>
+#include <linux/notifier.h>
+
+static BLOCKING_NOTIFIER_HEAD(input_notifier_list);
+
+/**
+ *	input_register_client - register a client notifier
+ *	@nb: notifier block to callback on events
+ */
+int input_register_client(struct notifier_block *nb)
+{
+        return blocking_notifier_chain_register(&input_notifier_list, nb);
+}
+EXPORT_SYMBOL(input_register_client);
+
+/**
+ *	input_unregister_client - unregister a client notifier
+ *	@nb: notifier block to callback on events
+ */
+int input_unregister_client(struct notifier_block *nb)
+{
+        return blocking_notifier_chain_unregister(&input_notifier_list, nb);
+}
+EXPORT_SYMBOL(input_unregister_client);
+
+/**
+ *	input_notifier_call_chain - notify clients of input_events
+ */
+int input_notifier_call_chain(unsigned long val, void *v)
+{
+        return blocking_notifier_call_chain(&input_notifier_list, val, v);
+}
+EXPORT_SYMBOL(input_notifier_call_chain);
diff --git a/include/linux/input.h b/include/linux/input.h
index 1249a0c..7e07bf3 100644
--- a/include/linux/input.h
+++ b/include/linux/input.h
@@ -1325,6 +1325,10 @@ static inline void input_set_abs_params(struct input_dev *dev, int axis, int min
 int input_get_keycode(struct input_dev *dev, int scancode, int *keycode);
 int input_set_keycode(struct input_dev *dev, int scancode, int keycode);
 
+extern int input_register_client(struct notifier_block *nb);
+extern int input_unregister_client(struct notifier_block *nb);
+extern int input_notifier_call_chain(unsigned long val, void *v);
+
 extern struct class input_class;
 
 /**

Re: [PATCH] Input notifier support

[Trilok Soni]

Hi Kyungmin,

On Wed, Feb 25, 2009 at 10:17 AM, Kyungmin Park <kmpark@infradead.org> wrote:
> Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.
>

I am not able to understand this.

> So add input notifier and then use it at other frameworks such as led.
> Of course, other input device can use this one.

If it is just LED, then you may write some led-input-trigger?

>
> Any commnets are welcome.

Could you please show example driver too, in-order to explain its usage. Thanks.

-- 
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni

Re: [PATCH] Input notifier support

[Kyungmin Park]

Hi,

On Wed, Feb 25, 2009 at 5:03 PM, Trilok Soni <soni.trilok@gmail.com> wrote:
> Hi Kyungmin,
>
> On Wed, Feb 25, 2009 at 10:17 AM, Kyungmin Park <kmpark@infradead.org> wrote:
>> Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.
>>
>
> I am not able to understand this.

it's simple there's one led and it's for key input. so when there's
key input, it's blink. that's all

>
>> So add input notifier and then use it at other frameworks such as led.
>> Of course, other input device can use this one.
>
> If it is just LED, then you may write some led-input-trigger?

Please see the LED key input trigger patch.

Thank you,
Kyungmin Park

Re: [PATCH] Input notifier support

[Trilok Soni]

Hi Kyungmin,

> diff --git a/drivers/input/input.c b/drivers/input/input.c
> index 1730d73..7e96635 100644
> --- a/drivers/input/input.c
> +++ b/drivers/input/input.c
> @@ -274,6 +274,8 @@ void input_event(struct input_dev *dev,
>                add_input_randomness(type, code, value);
>                input_handle_event(dev, type, code, value);
>                spin_unlock_irqrestore(&dev->event_lock, flags);
> +               if (type == EV_KEY)
> +                       input_notifier_call_chain(value, &code);

This check will be done for every input_report_xxx calls, even for
touchscreen events (in which case of course it will fail), and I don't
think this is optimal solution. Users should be given an option to
disable this if they don't need this notification mechanism.

How about moving this to input_report_key?

-- 
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Input notifier support

[Kyungmin Park]

Hi,

On Thu, Feb 26, 2009 at 4:01 PM, Trilok Soni <soni.trilok@gmail.com> wrote:
> Hi Kyungmin,
>
>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>> index 1730d73..7e96635 100644
>> --- a/drivers/input/input.c
>> +++ b/drivers/input/input.c
>> @@ -274,6 +274,8 @@ void input_event(struct input_dev *dev,
>>                add_input_randomness(type, code, value);
>>                input_handle_event(dev, type, code, value);
>>                spin_unlock_irqrestore(&dev->event_lock, flags);
>> +               if (type == EV_KEY)
>> +                       input_notifier_call_chain(value, &code);
>
> This check will be done for every input_report_xxx calls, even for
> touchscreen events (in which case of course it will fail), and I don't
> think this is optimal solution. Users should be given an option to
> disable this if they don't need this notification mechanism.
>
> How about moving this to input_report_key?

Good, Thank you for point it. I will move it to input_report_key.

Thank you,
Kyungmin Park

Re: [PATCH] Input notifier support

[Trilok Soni]

Hi Kyungmin,

On Fri, Feb 27, 2009 at 7:41 AM, Kyungmin Park <kmpark@infradead.org> wrote:
> Hi,
>
> On Thu, Feb 26, 2009 at 4:01 PM, Trilok Soni <soni.trilok@gmail.com> wrote:
>> Hi Kyungmin,
>>
>>> diff --git a/drivers/input/input.c b/drivers/input/input.c
>>> index 1730d73..7e96635 100644
>>> --- a/drivers/input/input.c
>>> +++ b/drivers/input/input.c
>>> @@ -274,6 +274,8 @@ void input_event(struct input_dev *dev,
>>>                add_input_randomness(type, code, value);
>>>                input_handle_event(dev, type, code, value);
>>>                spin_unlock_irqrestore(&dev->event_lock, flags);
>>> +               if (type == EV_KEY)
>>> +                       input_notifier_call_chain(value, &code);
>>
>> This check will be done for every input_report_xxx calls, even for
>> touchscreen events (in which case of course it will fail), and I don't
>> think this is optimal solution. Users should be given an option to
>> disable this if they don't need this notification mechanism.
>>
>> How about moving this to input_report_key?
>
> Good, Thank you for point it. I will move it to input_report_key.

As most of the other platforms may not need input_notify as standard
in-built feature, it is better to add Kconfig symbol for this, so that
it can be compiled out when not needed.


-- 
---Trilok Soni
http://triloksoni.wordpress.com
http://www.linkedin.com/in/triloksoni
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Input notifier support

[Dmitry Torokhov]

Hi Kyungmin,

On Wed, Feb 25, 2009 at 01:47:30PM +0900, Kyungmin Park wrote:
> Some hardware doesn't connected with key button and led. In this case
> key should be connected with led by software. Of course each application
> can control it however it's too big burden to application programmer.
> 
> So add input notifier and then use it at other frameworks such as led.
> Of course, other input device can use this one.
> 
> Any commnets are welcome.
> 

I don't think we need to do the notifier route. It is very easy to add
another input handler in style of rfkill-input or apm-power that would
listen to events from all ungrabbed input devices and act accordingly.
Your LED trigger example should work very well if implemented as another
input handler.

Thanks.

-- 
Dmitry

Re: [PATCH] Input notifier support

[Andi Kleen]

Kyungmin Park <kmpark@infradead.org> writes:

> Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.
>
> So add input notifier and then use it at other frameworks such as led.
> Of course, other input device can use this one.
>
> Any commnets are welcome.

It looks like the perfect interface for a password stealing root kit.

Yes there are probably other ways to do this, but still this seems to
make it very easy.

-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.

Re: [PATCH] Input notifier support

[Dmitry Torokhov]

On Sun, Mar 01, 2009 at 12:34:38AM +0100, Andi Kleen wrote:
> Kyungmin Park <kmpark@infradead.org> writes:
> 
> > Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.
> >
> > So add input notifier and then use it at other frameworks such as led.
> > Of course, other input device can use this one.
> >
> > Any commnets are welcome.
> 
> It looks like the perfect interface for a password stealing root kit.
> 
> Yes there are probably other ways to do this, but still this seems to
> make it very easy.
> 

We already have good interface for that. That's why you want to limit
access to /dev/input/eventX ;) and not make it world-readable.

-- 
Dmitry

Re: [PATCH] Input notifier support

[Kyungmin Park]

On Sun, Mar 1, 2009 at 9:42 AM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sun, Mar 01, 2009 at 12:34:38AM +0100, Andi Kleen wrote:
>> Kyungmin Park <kmpark@infradead.org> writes:
>>
>> > Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.
>> >
>> > So add input notifier and then use it at other frameworks such as led.
>> > Of course, other input device can use this one.
>> >
>> > Any commnets are welcome.
>>
>> It looks like the perfect interface for a password stealing root kit.
>>
>> Yes there are probably other ways to do this, but still this seems to
>> make it very easy.
>>
>
> We already have good interface for that. That's why you want to limit
> access to /dev/input/eventX ;) and not make it world-readable.
>

Hi Dmitry,

Could you tell me know which interface you're talking?
I agreed it's not good idea to pass key code value to drivers. it
caused security issues.

Thank you,
Kyungmin Park

Re: [PATCH] Input notifier support

[Dmitry Torokhov]

On Sun, Mar 01, 2009 at 11:52:56AM +0900, Kyungmin Park wrote:
> On Sun, Mar 1, 2009 at 9:42 AM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Sun, Mar 01, 2009 at 12:34:38AM +0100, Andi Kleen wrote:
> >> Kyungmin Park <kmpark@infradead.org> writes:
> >>
> >> > Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.
> >> >
> >> > So add input notifier and then use it at other frameworks such as led.
> >> > Of course, other input device can use this one.
> >> >
> >> > Any commnets are welcome.
> >>
> >> It looks like the perfect interface for a password stealing root kit.
> >>
> >> Yes there are probably other ways to do this, but still this seems to
> >> make it very easy.
> >>
> >
> > We already have good interface for that. That's why you want to limit
> > access to /dev/input/eventX ;) and not make it world-readable.
> >
> 
> Hi Dmitry,
> 
> Could you tell me know which interface you're talking?
> I agreed it's not good idea to pass key code value to drivers. it
> caused security issues.
> 

The interface to steal the root password. One can simply open all input
devices and read all events (if the process has sufficient rights).

-- 
Dmitry

Re: [PATCH] Input notifier support

[Kyungmin Park]

Hi,

On Sun, Mar 1, 2009 at 12:07 PM, Dmitry Torokhov
<dmitry.torokhov@gmail.com> wrote:
> On Sun, Mar 01, 2009 at 11:52:56AM +0900, Kyungmin Park wrote:
>> On Sun, Mar 1, 2009 at 9:42 AM, Dmitry Torokhov
>> <dmitry.torokhov@gmail.com> wrote:
>> > On Sun, Mar 01, 2009 at 12:34:38AM +0100, Andi Kleen wrote:
>> >> Kyungmin Park <kmpark@infradead.org> writes:
>> >>
>> >> > Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.
>> >> >
>> >> > So add input notifier and then use it at other frameworks such as led.
>> >> > Of course, other input device can use this one.
>> >> >
>> >> > Any commnets are welcome.
>> >>
>> >> It looks like the perfect interface for a password stealing root kit.
>> >>
>> >> Yes there are probably other ways to do this, but still this seems to
>> >> make it very easy.
>> >>
>> >
>> > We already have good interface for that. That's why you want to limit
>> > access to /dev/input/eventX ;) and not make it world-readable.
>> >
>>
>> Hi Dmitry,
>>
>> Could you tell me know which interface you're talking?
>> I agreed it's not good idea to pass key code value to drivers. it
>> caused security issues.
>>
>
> The interface to steal the root password. One can simply open all input
> devices and read all events (if the process has sufficient rights).
>
"I don't think we need to do the notifier route. It is very easy to add
another input handler in style of rfkill-input or apm-power that would
listen to events from all ungrabbed input devices and act accordingly.
Your LED trigger example should work very well if implemented as another
input handler."

Ah, I mean the this one, sorry for confusing you. You mean add led
trigger using input handler.
Then my question how to know which input device is connected trigger
As know it's input device is allocated by dynamically then how do we
know which input event is used and set?

Thank you,
Kyungmin Park

Re: [PATCH] Input notifier support

[Dmitry Torokhov]

On Sun, Mar 01, 2009 at 12:16:24PM +0900, Kyungmin Park wrote:
> Hi,
> 
> On Sun, Mar 1, 2009 at 12:07 PM, Dmitry Torokhov
> <dmitry.torokhov@gmail.com> wrote:
> > On Sun, Mar 01, 2009 at 11:52:56AM +0900, Kyungmin Park wrote:
> >> On Sun, Mar 1, 2009 at 9:42 AM, Dmitry Torokhov
> >> <dmitry.torokhov@gmail.com> wrote:
> >> > On Sun, Mar 01, 2009 at 12:34:38AM +0100, Andi Kleen wrote:
> >> >> Kyungmin Park <kmpark@infradead.org> writes:
> >> >>
> >> >> > Some hardware doesn't connected with key button and led. In this case key should be connected with led by software. Of course each application can control it however it's too big burden to application programmer.
> >> >> >
> >> >> > So add input notifier and then use it at other frameworks such as led.
> >> >> > Of course, other input device can use this one.
> >> >> >
> >> >> > Any commnets are welcome.
> >> >>
> >> >> It looks like the perfect interface for a password stealing root kit.
> >> >>
> >> >> Yes there are probably other ways to do this, but still this seems to
> >> >> make it very easy.
> >> >>
> >> >
> >> > We already have good interface for that. That's why you want to limit
> >> > access to /dev/input/eventX ;) and not make it world-readable.
> >> >
> >>
> >> Hi Dmitry,
> >>
> >> Could you tell me know which interface you're talking?
> >> I agreed it's not good idea to pass key code value to drivers. it
> >> caused security issues.
> >>
> >
> > The interface to steal the root password. One can simply open all input
> > devices and read all events (if the process has sufficient rights).
> >
> "I don't think we need to do the notifier route. It is very easy to add
> another input handler in style of rfkill-input or apm-power that would
> listen to events from all ungrabbed input devices and act accordingly.
> Your LED trigger example should work very well if implemented as another
> input handler."
> 
> Ah, I mean the this one, sorry for confusing you. You mean add led
> trigger using input handler.
> Then my question how to know which input device is connected trigger
> As know it's input device is allocated by dynamically then how do we
> know which input event is used and set?
> 

Umm, I am sorry, you lost me. Could you rephrase your question please?

-- 
Dmitry