[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <877iv4letm.fsf@gmx.it>
Date: Tue, 30 Jan 2007 16:22:29 +0100
From: Alessandro Di Marco <dmr@....it>
To: Vojtech Pavlik <vojtech@...e.cz>
Cc: Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: [ANNOUNCE] System Inactivity Monitor v1.0
Vojtech Pavlik <vojtech@...e.cz> writes:
> Mine problem here is that the input device doesn't care about suspend/resume
> cycles (it is a straight char driver), probably because it doesn't need to (so
> far.) Low-level drivers (kbd & co) on the contrary are all bus or platform
> drivers, hooking directly into suspend/resume callbacks.
>
> Do you mean that I should back-propagate a suspend/resume event from the
> low-level drivers to the input one?
Yes, but not as a callback, but instead as an input event.
Hum. Usually I'm not so dumb, really.
Problem) I need to know when the system goes to sleep in
drivers/input/input.c. For example, as a consequence of 'echo mem
>/sys/power/state'.
Solution 1) My ideal input layer model would be:
| SUBSYSTEM INPUT DEVICE* |
^ ^ ^ ^
+------+ | +----+ +------+ events
| | | |
|KEYBOARD| |MOUSE | |TOUCHSCREEN| |MISC |
|DEVICE | |DEVICE| |DEVICE | |DEVICE|
| SUBSYSTEM INPUT DEVICE* |
| | | |
+------+ | +----+ +------+ suspend()/resume() callbacks
v v v v
|KEYBOARD| |MOUSE | |TOUCHSCREEN| |MISC |
|DEVICE | |DEVICE| |DEVICE | |DEVICE|
Solution 2) On the contrary, you are suggesting to do this:
| INPUT DEVICE |
^ ^ ^ ^
+------+ | +----+ +------+ events plus
| | | | suspend/resume
|KEYBOARD | |MOUSE | |TOUCHSCREEN| |MISC |
|SUBSYSTEM| |SUBSYSTEM| |SUBSYSTEM | |SUBSYSTEM |
|DEVICE* | |DEVICE* | |DEVICE* | |DEVICE* |
Right?
* or whatever provides suspend/resume callbacks
--
>From their experience or from the recorded experience of others (history), men
learn only what their passions and their metaphysical prejudices allow them to
learn. - Aldous Huxley
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists