Hi all,
this is a new 2.6.20 module implementing a user inactivity trigger. Basically
it acts as an event sniffer, issuing an ACPI event when no user activity is
detected for more than a certain amount of time. This event can be successively
grabbed and managed by an user-level daemon such as acpid, blanking the screen,
dimming the lcd-panel light ? la mac, etc...
For the interested guys I have included a bash configuration helper (called
gentable) that covers the details.
Best,
On Thu, 2007-01-18 at 20:29 +0100, Alessandro Di Marco wrote:
> Hi all,
>
> this is a new 2.6.20 module implementing a user inactivity trigger. Basically
> it acts as an event sniffer, issuing an ACPI event when no user activity is
> detected for more than a certain amount of time. This event can be successively
> grabbed and managed by an user-level daemon such as acpid, blanking the screen,
> dimming the lcd-panel light à la mac, etc...
Hi,
why did you chose an ACPI event? I'd expect a uevent (which dbus
captures etc) to be a more logical choice..
Greetings,
Arjan van de Ven
Arjan van de Ven <[email protected]> writes:
On Thu, 2007-01-18 at 20:29 +0100, Alessandro Di Marco wrote:
> Hi all,
>
> this is a new 2.6.20 module implementing a user inactivity trigger. Basically
> it acts as an event sniffer, issuing an ACPI event when no user activity is
> detected for more than a certain amount of time. This event can be successively
> grabbed and managed by an user-level daemon such as acpid, blanking the screen,
> dimming the lcd-panel light ? la mac, etc...
Hi,
why did you chose an ACPI event? I'd expect a uevent (which dbus
captures etc) to be a more logical choice..
Laziness... :) Just an idea realized in a hurry to dim my laptop panel when it
is in idle (I don't use X11, so no xscreensaver et simila.)
Anyway I can accommodate it, if someone of you thinks that it is interesting
enough to be carried on the business.
The patch in attachment fixes some silly bugs of the previous version.
Regards,
On 1/19/07, Alessandro Di Marco <[email protected]> wrote:
> The patch in attachment fixes some silly bugs of the previous version.
>
> Regards,
Hi, attached is a patch for your gentable file, rewriting some of the
user prompts to make them more readable.
Regards,
scott
Alessandro Di Marco wrote:
> Hi all,
>
> this is a new 2.6.20 module implementing a user inactivity trigger. Basically
> it acts as an event sniffer, issuing an ACPI event when no user activity is
> detected for more than a certain amount of time. This event can be successively
> grabbed and managed by an user-level daemon such as acpid, blanking the screen,
> dimming the lcd-panel light ? la mac, etc...
Any idea how much power this saves? And for the vast rest of us who do
run X, this seems to parallel the work of a well-tuned screensaver.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
On Jan 19 2007 11:45, Scott Preece wrote:
> Hi, attached is a patch for your gentable file, rewriting some of the
> user prompts to make them more readable.
I still don't get why this is called "SIN" in the Kconfig and code texts
though the acronym for System Inactivity Monitor would be "SIM".
-`J'
--
On 1/19/07, Jan Engelhardt <[email protected]> wrote:
>
> On Jan 19 2007 11:45, Scott Preece wrote:
> > Hi, attached is a patch for your gentable file, rewriting some of the
> > user prompts to make them more readable.
>
> I still don't get why this is called "SIN" in the Kconfig and code texts
> though the acronym for System Inactivity Monitor would be "SIM".
---
The code calls it "System Inactivity Notifier".
scott
Bill Davidsen <[email protected]> writes:
Alessandro Di Marco wrote:
> Hi all,
>
> this is a new 2.6.20 module implementing a user inactivity trigger. Basically
> it acts as an event sniffer, issuing an ACPI event when no user activity is
> detected for more than a certain amount of time. This event can be successively
> grabbed and managed by an user-level daemon such as acpid, blanking the screen,
> dimming the lcd-panel light ? la mac, etc...
Any idea how much power this saves? And for the vast rest of us who do run X,
this seems to parallel the work of a well-tuned screensaver.
This is just a notifier; to make it work as a screensaver you'll have to rely
on some external programs. Personally I use smartdimmer to dim my vaio panel.
Obviously you can keep your toaster flying, if you like, simply calling the
flying-toaster module instead of smartdimmer. Anyway I would use the latter on
battery. ;-)
Best,
--
"What made the deepest impression upon you?" inquired a friend one day of
Lincoln, "when you stood in the presence of the Falls of Niagara, the greatest
of natural wonders?" ---- "The thing that stuck me most forcibly when I saw the
Falls," Lincoln responded with the characteristic deliberation, "was where in
the world did all that water come from?" - Author Unknown
HiQ
> this is a new 2.6.20 module implementing a user inactivity trigger. Basically
> it acts as an event sniffer, issuing an ACPI event when no user activity is
> detected for more than a certain amount of time. This event can be successively
> grabbed and managed by an user-level daemon such as acpid, blanking the screen,
> dimming the lcd-panel light ? la mac, etc...
While functionality is extremely interesting.... does it really have
to be in kernel?
> +if [ ! -d "/proc/sin" ]; then
> + echo "/proc/sin not found, has sinmod been loaded?"
> + exit
> +fi
No new /proc files, please.
> +cat <<EOF
> +
> +SIN wakes up periodically and checks for user activity occurred in the
> +meantime; this options lets you to specify how much frequently SIN should be
> +woken-up. Its value is expressed in tenth of seconds.
Heh. We'll waste power trying to save it. If you have to hook it into
kernel, can you at least do it properly?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Jan 19 2007 10:11, Pavel Machek wrote:
>
>> this is a new 2.6.20 module implementing a user inactivity trigger. Basically
>> it acts as an event sniffer, issuing an ACPI event when no user activity is
>> detected for more than a certain amount of time. This event can be successively
>> grabbed and managed by an user-level daemon such as acpid, blanking the screen,
>> dimming the lcd-panel light ? la mac, etc...
>
>While functionality is extremely interesting.... does it really have
>to be in kernel?
I think so. While the X server grabs off any keyboard and mouse activity
on its own, there is no such thing for the [read "all"] console[s].
Mouse movement (e.g. GPM) is actually implemented in the kernel,
and screen blanking (the one controlled with "\e[9;x]") is too.
-`J'
--
Hi!
> >While functionality is extremely interesting.... does it really have
> >to be in kernel?
>
> I think so. While the X server grabs off any keyboard and mouse activity
> on its own, there is no such thing for the [read "all"] console[s].
I believe input subsystem can already do that.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> > +if [ ! -d "/proc/sin" ]; then
> > + echo "/proc/sin not found, has sinmod been loaded?"
> > + exit
> > +fi
>
> No new /proc files, please.
>
> This was merely a prototype realized in a hurry, not a production
> driver. Really, I did't think it could be interesting for anybody.
>
> Would be /sys ok?
If it has to be in kernel, /sys/power is probably ok. But I still
believe it can be out.
Yes, I believe it is interesting: on modern machine, you want to
control keyboard illumination, lower backlight after short inactivity,
turn screen off after longer one, etc...
> Heh. We'll waste power trying to save it.
>
> Well, not just a power saver. For example I use SIN to auto-logoff my bash
> session as well (detaching the screen session.)
Ok, ok :-).
> If you have to hook it into kernel, can you at least do it properly?
>
> Of course. You can find attached a patch fixing this. Now SIN wakes up just
> when it expects to do something: if in the meantime the user interacts with the
> system, SIN simply recalculates the next wake-up time on the basis of the last
> user's activity date and goes to sleep again.
Good.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi1
> > > +if [ ! -d "/proc/sin" ]; then
> > > + echo "/proc/sin not found, has sinmod been loaded?"
> > > + exit
> > > +fi
> >
> > No new /proc files, please.
> >
> > This was merely a prototype realized in a hurry, not a production
> > driver. Really, I did't think it could be interesting for anybody.
> >
> > Would be /sys ok?
>
> If it has to be in kernel, /sys/power is probably ok.
>
> Doh! The attached patch introduces /sys/class/misc (along with some bug-fixes.)
> In case I'll change it again.
No, just leave it where it is. Maybe better location will be invented,
but mine idea was just first shot.
> But I still believe it can be out.
>
> Do you believe it could be a user-space daemon or what?
Yes, what prevents userspace daemon watching /dev/input/event* to
provide this functionality?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek <[email protected]> writes:
> But I still believe it can be out.
>
> Do you believe it could be a user-space daemon or what?
Yes, what prevents userspace daemon watching /dev/input/event* to
provide this functionality?
Well that was my first attempt. Just an hack, but it works. Nonetheless I found
the kernel-level approach fitting better the problem: it is elegant, simpler
and more efficient than user-level one.
For example, the subsystem provides at kernel-level handy
hiberante/suspend/resume callbacks that I use to turn on/off the timer,
avoiding the time-warp problem. Doing that at user-level would be far more
messy...
Bye
--
An age is called Dark not because the light fails to shine, but because people
refuse to see it. - James Michener, Space
Hi!
> > But I still believe it can be out.
> >
> > Do you believe it could be a user-space daemon or what?
>
> Yes, what prevents userspace daemon watching /dev/input/event* to
> provide this functionality?
>
> Well that was my first attempt. Just an hack, but it works. Nonetheless I found
> the kernel-level approach fitting better the problem: it is elegant, simpler
> and more efficient than user-level one.
Well, unfortunately it is also wrong thing to do :-(.
> For example, the subsystem provides at kernel-level handy
> hiberante/suspend/resume callbacks that I use to turn on/off the timer,
> avoiding the time-warp problem. Doing that at user-level would be far more
> messy...
Imagine for a moment that we solve time-warp somehow. Any other
problems? [I'd really like to get "is user idle" solved, but it really
should not be in kernel unless it _has_ to. And time-warp probably
causes problems not only for your daemon.]
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Tue, Jan 23, 2007 at 05:34:42PM +0100, Pavel Machek wrote:
[...]
> > Do you believe it could be a user-space daemon or what?
>
> Yes, what prevents userspace daemon watching /dev/input/event* to
> provide this functionality?
hmmm... EVIOCGRAB for example? the synaptics Xorg driver is using
it, maybe others too?
I don't want to start a new discussion about it, just provide an answer
to your question :)
--
mattia
:wq!
On Tue 2007-01-23 20:01:07, Mattia Dongili wrote:
> On Tue, Jan 23, 2007 at 05:34:42PM +0100, Pavel Machek wrote:
> [...]
> > > Do you believe it could be a user-space daemon or what?
> >
> > Yes, what prevents userspace daemon watching /dev/input/event* to
> > provide this functionality?
>
> hmmm... EVIOCGRAB for example? the synaptics Xorg driver is using
> it, maybe others too?
> I don't want to start a new discussion about it, just provide an answer
> to your question :)
I do not know how EVIOCGRAB works, I believe event* will _still_ see
the events. Anyway, if not, I guess EVIOCGRAB can be fixed/removed/ we
can add EVIOCGIVEMEALLTHEDATAREALLYIWANTIT.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On 1/23/07, Pavel Machek <[email protected]> wrote:
> Hi1
> ...
> >
>
> > But I still believe it can be out.
> >
> > Do you believe it could be a user-space daemon or what?
>
> Yes, what prevents userspace daemon watching /dev/input/event* to
> provide this functionality?
> Pavel
---
One possible argument is to allow integrating "input-like" user events
with other kinds of system-level events that you might want to have
treated like user activity. For instance, our definition of user
activity includes: button presses, opening-closing the cover (on a
phone), and plugging in or removing memory cards, accessories, or
cables. We actually use a mix of kernel and user-space monitoring,
today, but would prefer an integrated monitor.
A user-space monitor also has more opportunity for races - for
instance, deciding that the inactivity timeout has occurred between
the time that the user does something and the time that the kernel
gets a notification up to user space.
My own hot button is making sure that the definition of what
constitutes user activity is managed in exactly one place, whether in
the kernel or not. My naive model would be to put the response at user
level, but to provide a single point of definition in the kernel (say,
/dev/useractivity or the equivalent) that the user-level daemon could
listen to.
scott
On Tue, Jan 23, 2007 at 08:02:57PM +0100, Pavel Machek wrote:
> On Tue 2007-01-23 20:01:07, Mattia Dongili wrote:
> > On Tue, Jan 23, 2007 at 05:34:42PM +0100, Pavel Machek wrote:
> > [...]
> > > > Do you believe it could be a user-space daemon or what?
> > >
> > > Yes, what prevents userspace daemon watching /dev/input/event* to
> > > provide this functionality?
> >
> > hmmm... EVIOCGRAB for example? the synaptics Xorg driver is using
> > it, maybe others too?
> > I don't want to start a new discussion about it, just provide an answer
> > to your question :)
>
> I do not know how EVIOCGRAB works, I believe event* will _still_ see
AFAIK once an opener has eviocgrab-ed the device no other opener will
receive events.
> the events. Anyway, if not, I guess EVIOCGRAB can be fixed/removed/ we
> can add EVIOCGIVEMEALLTHEDATAREALLYIWANTIT.
then probably pbuttonsd is already doing something similar to SI[NM]
hmmm... was it pbuttonsd? oh, yes:
http://pbbuttons.sourceforge.net/projects/pbbuttonsd/
--
mattia
:wq!
"Scott Preece" <[email protected]> writes:
My own hot button is making sure that the definition of what
constitutes user activity is managed in exactly one place, whether in
the kernel or not. My naive model would be to put the response at user
level, but to provide a single point of definition in the kernel (say,
/dev/useractivity or the equivalent) that the user-level daemon could
listen to.
Unfortunately the term "user activity" seems a bit too vague for this. IMHO
different users (but also applications) present different needs that you cannot
fit with a single device node.
Example. The user expects that the keyboard light is turned off after 10
minutes of keyboard inactivity, disregarding the mouse movements. This makes
sense since the glare at the bottom disturb the Quake sessions. :-) However when
the screen is blanked, the user expects that either keyboard or mouse events
can unblank it...
--
All of the significant battles are waged within the self. - Sheldon Kopp
Pavel Machek <[email protected]> writes:
Imagine for a moment that we solve time-warp somehow. Any other
problems?
Well, a user-level daemon have to process a lot of data just to detect user
interaction. Considering that the trackpad bandwidth is nearly 5KB/sec,
probably would be better to leave my panel alone... :-/
I'd really like to get "is user idle" solved, but it really should not be in
kernel unless it _has_ to. And time-warp probably causes problems not only
for your daemon.
IMHO signal the user-space is a kernel duty and no user-space daemon will ever
make it better. There are plenty of PM daemons out there, but Linux still lacks
of a decent power management. Thanks to SIN, acpid and a silly bash script I'm
able to save a lot of battery and furthermore, when my friends see the dimming
panel they break out: WOW, how do you succeed in running MacOS on your Vaio!?!
:-(
Best,
--
Gratitude is not only the greatest of virtues, but the parent of all the
others. - Cicero
Scott Preece <[email protected]> wrote:
> My own hot button is making sure that the definition of what
> constitutes user activity is managed in exactly one place, whether in
> the kernel or not. My naive model would be to put the response at user
> level, but to provide a single point of definition in the kernel (say,
> /dev/useractivity or the equivalent) that the user-level daemon could
> listen to.
Imagine one computer serving two users. Two monitors, two keyboards ...
--
Funny quotes:
38. Last night I played a blank tape at full blast. The mime next door went
nuts.
Fri?, Spammer: [email protected]
On 1/25/07, Bodo Eggert <[email protected]> wrote:
> Scott Preece <[email protected]> wrote:
>
> > My own hot button is making sure that the definition of what
> > constitutes user activity is managed in exactly one place, whether in
> > the kernel or not. My naive model would be to put the response at user
> > level, but to provide a single point of definition in the kernel (say,
> > /dev/useractivity or the equivalent) that the user-level daemon could
> > listen to.
>
> Imagine one computer serving two users. Two monitors, two keyboards ...
---
Good point! Of late I've been working on single-user systems, so it
was not at the front of my brain, despite years of building and using
multi-user systems.
It's a point that multi-user systems have struggled with forever (when
somebody inserts a CR in the drive mounted in the system box, which
user do you pop up a media player for?).
I tend to think it's not a kernel-vs-user-space issue, though. To
solve it you need, somewhere, a notion of a "user session" and you
need some way to separate system-level issues (like low-battery) from
user-level issues (like activiating user X's screensaver).
"Scott Preece" <[email protected]> writes:
On 1/25/07, Bodo Eggert <[email protected]> wrote:
> Imagine one computer serving two users. Two monitors, two keyboards ...
---
Good point! Of late I've been working on single-user systems, so it
was not at the front of my brain, despite years of building and using
multi-user systems.
It's a point that multi-user systems have struggled with forever (when
somebody inserts a CR in the drive mounted in the system box, which user do
you pop up a media player for?).
sed s/user X's screensaver/suspend to disk/g <<EOF
I tend to think it's not a kernel-vs-user-space issue, though. To
solve it you need, somewhere, a notion of a "user session" and you
need some way to separate system-level issues (like low-battery) from
user-level issues (like activiating user X's screensaver).
EOF
Are you sure?
best,
--
Experience teaches slowly and at the cost of mistakes. - James A. Froude
On 1/25/07, Alessandro Di Marco <[email protected]> wrote:
> "Scott Preece" <[email protected]> writes:
>
> On 1/25/07, Bodo Eggert <[email protected]> wrote:
> > Imagine one computer serving two users. Two monitors, two keyboards ...
> ---
>
> Good point! Of late I've been working on single-user systems, so it
> was not at the front of my brain, despite years of building and using
> multi-user systems.
>
> It's a point that multi-user systems have struggled with forever (when
> somebody inserts a CR in the drive mounted in the system box, which user do
> you pop up a media player for?).
>
> sed s/user X's screensaver/suspend to disk/g <<EOF
>
> I tend to think it's not a kernel-vs-user-space issue, though. To
> solve it you need, somewhere, a notion of a "user session" and you
> need some way to separate system-level issues (like low-battery) from
> user-level issues (like activiating user X's screensaver).
>
> EOF
>
> Are you sure?
---
Well, a screensaver is associated with a particular user (and screen),
but suspend-to-disk is a system-wide activity that would affect all
the users. So you need to be able to separate those notions in
deciding what actions to take.
scott
Hi!
> >
> >> But I still believe it can be out.
> >>
> >> Do you believe it could be a user-space daemon or
> >what?
> >
> >Yes, what prevents userspace daemon watching
> >/dev/input/event* to
> >provide this functionality?
> > Pavel
> ---
>
> One possible argument is to allow integrating
> "input-like" user events
> with other kinds of system-level events that you might
> want to have
> treated like user activity. For instance, our definition
> of user
> activity includes: button presses, opening-closing the
> cover (on a
> phone), and plugging in or removing memory cards,
> accessories, or
> cables. We actually use a mix of kernel and user-space
> monitoring,
Well... input already has 'pseudokey' for lid, and yes, you
probably can monitor cover, memory cards and cables from userspace,
already... as you do. Cover, and maybe even cards/cables could be
integrated with input infrastructure, too.
(Still waiting for you to start selling those cool phones in czech
republic :-).
> A user-space monitor also has more opportunity for races
> - for
> instance, deciding that the inactivity timeout has
> occurred between
> the time that the user does something and the time that
> the kernel
> gets a notification up to user space.
Same races are inside kernel, too.
> My own hot button is making sure that the definition of
> what
> constitutes user activity is managed in exactly one
> place, whether in
> the kernel or not. My naive model would be to put the
> response at user
> level, but to provide a single point of definition in
> the kernel (say,
> /dev/useractivity or the equivalent) that the user-level
> daemon could
> listen to.
Actually, I believe right solution is to provide one, unified,
monitoring daemon, using whatever interfaces are available. (+ add
missing functionality to the kernel, if neccessary).
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> Imagine for a moment that we solve time-warp somehow. Any other
> problems?
>
> Well, a user-level daemon have to process a lot of data just to detect user
> interaction. Considering that the trackpad bandwidth is nearly 5KB/sec,
> probably would be better to leave my panel alone... :-/
Ok, so we may want to introduce something like "tell me if some data
came from last time"... Actually, 5KB/sec is pretty much okay, and you
probably could get around actually reading that data.
When you know user is moving the touchpad, you could just sleep for 5
seconds (assuming user activity) and only then start monitoring it
again?
> I'd really like to get "is user idle" solved, but it really should not be in
> kernel unless it _has_ to. And time-warp probably causes problems not only
> for your daemon.
>
> IMHO signal the user-space is a kernel duty and no user-space daemon will ever
> make it better. There are plenty of PM daemons out there, but Linux still lacks
Well, I do not think your kernel code is mergeable. But bits to enable
similar functionality in userspace probably would be mergeable.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Hi!
> Well, I do not think your kernel code is mergeable. But bits to enable
> similar functionality in userspace probably would be mergeable.
>
> You said it :-)
>
> This patch exports to the user space the inactivity time (in msecs) of a given
> input device. Example follows:
Looks okay to me. I guess you should sign it off, and ask Dmitry
(input maintainer) for a merge?
> <0> $ cat /proc/bus/input/activity
> 0011 0001 0001 ab41 1
> 0011 0002 0008 0000 3160799
> 0011 0002 0008 7321 549991
> 0019 0000 0005 0000 3160799
> 0019 0000 0001 0000 3454901
> 0010 104d 0000 0000 3160799
> 0010 104d 0000 0000 2162833
>
> The device ordering matches the /proc/bus/input/devices one, anyway I reported
> also vendor, product, etc. Now the daemon is trivial...
> @@ -482,6 +484,30 @@
> return seq_open(file, &input_devices_seq_ops);
> }
>
> +static int input_activity_seq_show(struct seq_file *seq, void *v)
> +{
> + struct input_dev *dev = container_of(v, struct input_dev, node);
> +
> + seq_printf(seq, "%04x %04x %04x %04x\t%u\n",
> + dev->id.bustype, dev->id.vendor,
> + dev->id.product, dev->id.version,
> + jiffies_to_msecs((long) jiffies - (long) dev->last_activity));
> +
> + return 0;
> +}
> +
> +static struct seq_operations input_activity_seq_ops = {
> + .start = input_devices_seq_start,
> + .next = input_devices_seq_next,
> + .stop = input_devices_seq_stop,
> + .show = input_activity_seq_show,
> +};
> +
> +static int input_proc_activity_open(struct inode *inode, struct file *file)
> +{
> + return seq_open(file, &input_activity_seq_ops);
> +}
> +
> static struct file_operations input_devices_fileops = {
> .owner = THIS_MODULE,
> .open = input_proc_devices_open,
> @@ -491,6 +517,15 @@
> .release = seq_release,
> };
>
> +static struct file_operations input_activity_fileops = {
> + .owner = THIS_MODULE,
> + .open = input_proc_activity_open,
> + .poll = input_proc_devices_poll,
> + .read = seq_read,
> + .llseek = seq_lseek,
> + .release = seq_release,
> +};
> +
> static void *input_handlers_seq_start(struct seq_file *seq, loff_t *pos)
> {
> /* acquire lock here ... Yes, we do need locking, I knowi, I know... */
> @@ -558,15 +593,23 @@
> entry->owner = THIS_MODULE;
> entry->proc_fops = &input_devices_fileops;
>
> - entry = create_proc_entry("handlers", 0, proc_bus_input_dir);
> + entry = create_proc_entry("activity", 0, proc_bus_input_dir);
> if (!entry)
> goto fail2;
>
> entry->owner = THIS_MODULE;
> + entry->proc_fops = &input_activity_fileops;
> +
> + entry = create_proc_entry("handlers", 0, proc_bus_input_dir);
> + if (!entry)
> + goto fail3;
> +
> + entry->owner = THIS_MODULE;
> entry->proc_fops = &input_handlers_fileops;
>
> return 0;
>
> + fail3: remove_proc_entry("activity", proc_bus_input_dir);
> fail2: remove_proc_entry("devices", proc_bus_input_dir);
> fail1: remove_proc_entry("input", proc_bus);
> return -ENOMEM;
> diff -ur OLD/include/linux/input.h NEW/include/linux/input.h
> --- OLD/include/linux/input.h 2007-01-26 16:59:38.000000000 +0100
> +++ NEW/include/linux/input.h 2007-01-26 17:31:29.000000000 +0100
> @@ -949,6 +949,8 @@
> const char *uniq;
> struct input_id id;
>
> + unsigned long last_activity;
> +
> unsigned long evbit[NBITS(EV_MAX)];
> unsigned long keybit[NBITS(KEY_MAX)];
> unsigned long relbit[NBITS(REL_MAX)];
>
> --
> I don't think anyone should write their autobiography until after they're
> dead. - Samuel Goldwyn
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Sat, Jan 27, 2007 at 05:45:25PM +0000, Pavel Machek wrote:
> Hi!
>
> > Well, I do not think your kernel code is mergeable. But bits to enable
> > similar functionality in userspace probably would be mergeable.
> >
> > You said it :-)
> >
> > This patch exports to the user space the inactivity time (in msecs) of a given
> > input device. Example follows:
>
> Looks okay to me. I guess you should sign it off, and ask Dmitry
> (input maintainer) for a merge?
The /proc/bus/input/devices has an extensible structure. You can just
add an "A:" line (for Activity) instead of adding a new proc file.
Anyway, I believe this should be also available through sysfs, if not
only there.
Also, the activity counters should IMO coincide with the event times
passed through /dev/input/event, and should not be jiffies based.
Ideally, both should be based on clock_gettime(CLOCK_MONOTONIC).
> > <0> $ cat /proc/bus/input/activity
> > 0011 0001 0001 ab41 1
> > 0011 0002 0008 0000 3160799
> > 0011 0002 0008 7321 549991
> > 0019 0000 0005 0000 3160799
> > 0019 0000 0001 0000 3454901
> > 0010 104d 0000 0000 3160799
> > 0010 104d 0000 0000 2162833
> >
> > The device ordering matches the /proc/bus/input/devices one, anyway I reported
> > also vendor, product, etc. Now the daemon is trivial...
>
> > @@ -482,6 +484,30 @@
> > return seq_open(file, &input_devices_seq_ops);
> > }
> >
> > +static int input_activity_seq_show(struct seq_file *seq, void *v)
> > +{
> > + struct input_dev *dev = container_of(v, struct input_dev, node);
> > +
> > + seq_printf(seq, "%04x %04x %04x %04x\t%u\n",
> > + dev->id.bustype, dev->id.vendor,
> > + dev->id.product, dev->id.version,
> > + jiffies_to_msecs((long) jiffies - (long) dev->last_activity));
> > +
> > + return 0;
> > +}
> > +
> > +static struct seq_operations input_activity_seq_ops = {
> > + .start = input_devices_seq_start,
> > + .next = input_devices_seq_next,
> > + .stop = input_devices_seq_stop,
> > + .show = input_activity_seq_show,
> > +};
> > +
> > +static int input_proc_activity_open(struct inode *inode, struct file *file)
> > +{
> > + return seq_open(file, &input_activity_seq_ops);
> > +}
> > +
> > static struct file_operations input_devices_fileops = {
> > .owner = THIS_MODULE,
> > .open = input_proc_devices_open,
> > @@ -491,6 +517,15 @@
> > .release = seq_release,
> > };
> >
> > +static struct file_operations input_activity_fileops = {
> > + .owner = THIS_MODULE,
> > + .open = input_proc_activity_open,
> > + .poll = input_proc_devices_poll,
> > + .read = seq_read,
> > + .llseek = seq_lseek,
> > + .release = seq_release,
> > +};
> > +
> > static void *input_handlers_seq_start(struct seq_file *seq, loff_t *pos)
> > {
> > /* acquire lock here ... Yes, we do need locking, I knowi, I know... */
> > @@ -558,15 +593,23 @@
> > entry->owner = THIS_MODULE;
> > entry->proc_fops = &input_devices_fileops;
> >
> > - entry = create_proc_entry("handlers", 0, proc_bus_input_dir);
> > + entry = create_proc_entry("activity", 0, proc_bus_input_dir);
> > if (!entry)
> > goto fail2;
> >
> > entry->owner = THIS_MODULE;
> > + entry->proc_fops = &input_activity_fileops;
> > +
> > + entry = create_proc_entry("handlers", 0, proc_bus_input_dir);
> > + if (!entry)
> > + goto fail3;
> > +
> > + entry->owner = THIS_MODULE;
> > entry->proc_fops = &input_handlers_fileops;
> >
> > return 0;
> >
> > + fail3: remove_proc_entry("activity", proc_bus_input_dir);
> > fail2: remove_proc_entry("devices", proc_bus_input_dir);
> > fail1: remove_proc_entry("input", proc_bus);
> > return -ENOMEM;
> > diff -ur OLD/include/linux/input.h NEW/include/linux/input.h
> > --- OLD/include/linux/input.h 2007-01-26 16:59:38.000000000 +0100
> > +++ NEW/include/linux/input.h 2007-01-26 17:31:29.000000000 +0100
> > @@ -949,6 +949,8 @@
> > const char *uniq;
> > struct input_id id;
> >
> > + unsigned long last_activity;
> > +
> > unsigned long evbit[NBITS(EV_MAX)];
> > unsigned long keybit[NBITS(KEY_MAX)];
> > unsigned long relbit[NBITS(REL_MAX)];
>
> >
> > --
> > I don't think anyone should write their autobiography until after they're
> > dead. - Samuel Goldwyn
>
>
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
>
--
Vojtech Pavlik
Director SuSE Labs
On Sat, Jan 27, 2007 at 05:45:25PM +0000, Pavel Machek wrote:
> > This patch exports to the user space the inactivity time (in msecs) of a given
> > input device. Example follows:
>
> Looks okay to me. I guess you should sign it off, and ask Dmitry
> (input maintainer) for a merge?
Hey, come on, "no new proc files", please ;-)
> > <0> $ cat /proc/bus/input/activity
--
Stefan Seyfried
QA / R&D Team Mobile Devices | "Any ideas, John?"
SUSE LINUX Products GmbH, N?rnberg | "Well, surrounding them's out."
Vojtech Pavlik <[email protected]> writes:
On Sat, Jan 27, 2007 at 05:45:25PM +0000, Pavel Machek wrote:
> Hi!
>
> > Well, I do not think your kernel code is mergeable. But bits to enable
> > similar functionality in userspace probably would be mergeable.
> >
> > You said it :-)
> >
> > This patch exports to the user space the inactivity time (in msecs) of a given
> > input device. Example follows:
>
> Looks okay to me. I guess you should sign it off, and ask Dmitry
> (input maintainer) for a merge?
Pavel, the submitted patch was not meant for production use: it still suffers
of the time-warp problem. To fix it I need to know when the system goes to
sleep/resumes. In SIN I've solved via the platform driver, introducing
suspend() resume() callbacks. What do you think about?
The /proc/bus/input/devices has an extensible structure. You can just
add an "A:" line (for Activity) instead of adding a new proc file.
I know, but IMO there is too much stuff to parse in there. Activity counters
are frequently accessed by daemons, and four or five concurrent daemons are the
norm in a typical X11 linux box...
Anyway, I believe this should be also available through sysfs, if not
only there.
Pavel gives me clearance for only bits of code, so I've recycled something
already done. No problem for me to switch /sys.
Also, the activity counters should IMO coincide with the event times
passed through /dev/input/event, and should not be jiffies based.
Ideally, both should be based on clock_gettime(CLOCK_MONOTONIC).
In evdev.c do_gettimeofday() is used. Anyway I just need of a monotonic
counter, so get_jiffies_64() wouldn't be better? It isn't affected by wrapping
issues and it is probably faster than do_gtod().
Best,
--
Ambition is a poor excuse for not having sense enough to be lazy. - Edgar Bergen
Hi!
> The /proc/bus/input/devices has an extensible structure. You can just
> add an "A:" line (for Activity) instead of adding a new proc file.
>
> I know, but IMO there is too much stuff to parse in there. Activity counters
> are frequently accessed by daemons, and four or five concurrent daemons are the
> norm in a typical X11 linux box...
Syscalls are fast enough, and the file is _very_ easy (=> fast) to parse.
> Also, the activity counters should IMO coincide with the event times
> passed through /dev/input/event, and should not be jiffies based.
> Ideally, both should be based on clock_gettime(CLOCK_MONOTONIC).
>
> In evdev.c do_gettimeofday() is used. Anyway I just need of a monotonic
> counter, so get_jiffies_64() wouldn't be better? It isn't affected by wrapping
> issues and it is probably faster than do_gtod().
Just use same time source rest of inputs already do...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Pavel Machek <[email protected]> writes:
Hi!
> The /proc/bus/input/devices has an extensible structure. You can just
> add an "A:" line (for Activity) instead of adding a new proc file.
>
> I know, but IMO there is too much stuff to parse in there. Activity counters
> are frequently accessed by daemons, and four or five concurrent daemons are the
> norm in a typical X11 linux box...
Syscalls are fast enough, and the file is _very_ easy (=> fast) to parse.
> Also, the activity counters should IMO coincide with the event times
> passed through /dev/input/event, and should not be jiffies based.
> Ideally, both should be based on clock_gettime(CLOCK_MONOTONIC).
>
> In evdev.c do_gettimeofday() is used. Anyway I just need of a monotonic
> counter, so get_jiffies_64() wouldn't be better? It isn't affected by wrapping
> issues and it is probably faster than do_gtod().
Just use same time source rest of inputs already do...
OK, but what about the time-warp problem?. To fix it I need to know when the
system goes to sleep/resumes. In SIN I've solved via the platform driver,
introducing suspend() resume() callbacks...
greets,
--
Technology is dominated by two types of people: those who understand what they
do not manage, and those who manage what they do not understand. - Putt's Law
Hi!
> > The /proc/bus/input/devices has an extensible structure. You can just
> > add an "A:" line (for Activity) instead of adding a new proc file.
> >
> > I know, but IMO there is too much stuff to parse in there. Activity counters
> > are frequently accessed by daemons, and four or five concurrent daemons are the
> > norm in a typical X11 linux box...
>
> Syscalls are fast enough, and the file is _very_ easy (=> fast) to parse.
>
> > Also, the activity counters should IMO coincide with the event times
> > passed through /dev/input/event, and should not be jiffies based.
> > Ideally, both should be based on clock_gettime(CLOCK_MONOTONIC).
> >
> > In evdev.c do_gettimeofday() is used. Anyway I just need of a monotonic
> > counter, so get_jiffies_64() wouldn't be better? It isn't affected by wrapping
> > issues and it is probably faster than do_gtod().
>
> Just use same time source rest of inputs already do...
>
> OK, but what about the time-warp problem?. To fix it I need to know when the
> system goes to sleep/resumes. In SIN I've solved via the platform driver,
> introducing suspend() resume() callbacks...
input drivers will already have suspend() resume() callbacks... could
you reuse those?
...hmm, I see no easy place where to hook these. You could reuse your
platform device trick, I guess... but maybe there's a better way?
Vojtech, do we have some "global" hooks for input suspend/resume? This
code is global to all the devices, but still needs to know about
suspend/resume...
Or we could create notifier list, where interested parties would be
informed of suspend/resume...
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Mon, Jan 29, 2007 at 11:42:08PM +0100, Alessandro Di Marco wrote:
> Pavel Machek <[email protected]> writes:
>
> Hi!
>
> > The /proc/bus/input/devices has an extensible structure. You can just
> > add an "A:" line (for Activity) instead of adding a new proc file.
> >
> > I know, but IMO there is too much stuff to parse in there. Activity counters
> > are frequently accessed by daemons, and four or five concurrent daemons are the
> > norm in a typical X11 linux box...
>
> Syscalls are fast enough, and the file is _very_ easy (=> fast) to parse.
>
> > Also, the activity counters should IMO coincide with the event times
> > passed through /dev/input/event, and should not be jiffies based.
> > Ideally, both should be based on clock_gettime(CLOCK_MONOTONIC).
> >
> > In evdev.c do_gettimeofday() is used. Anyway I just need of a monotonic
> > counter, so get_jiffies_64() wouldn't be better? It isn't affected by wrapping
> > issues and it is probably faster than do_gtod().
>
> Just use same time source rest of inputs already do...
>
> OK, but what about the time-warp problem?. To fix it I need to know when the
> system goes to sleep/resumes. In SIN I've solved via the platform driver,
> introducing suspend() resume() callbacks...
Well, you just need to make sure that a resume() actually is a visible
event ...
--
Vojtech Pavlik
Director SuSE Labs
Vojtech Pavlik <[email protected]> writes:
On Mon, Jan 29, 2007 at 11:42:08PM +0100, Alessandro Di Marco wrote:
> OK, but what about the time-warp problem?. To fix it I need to know when the
> system goes to sleep/resumes. In SIN I've solved via the platform driver,
> introducing suspend() resume() callbacks...
Well, you just need to make sure that a resume() actually is a visible
event ...
Sorry, but I don't see the point. Visible to what?
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?
--
There is only one thing a philosopher can be relied upon to do, and that is to
contradict other philosophers. - William James
On Tue, Jan 30, 2007 at 01:33:10PM +0100, Alessandro Di Marco wrote:
> Vojtech Pavlik <[email protected]> writes:
>
> On Mon, Jan 29, 2007 at 11:42:08PM +0100, Alessandro Di Marco wrote:
>
> > OK, but what about the time-warp problem?. To fix it I need to know when the
> > system goes to sleep/resumes. In SIN I've solved via the platform driver,
> > introducing suspend() resume() callbacks...
>
> Well, you just need to make sure that a resume() actually is a visible
> event ...
>
> Sorry, but I don't see the point. Visible to what?
Counted as activity.
> 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.
--
Vojtech Pavlik
Director SuSE Labs
Vojtech Pavlik <[email protected]> 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