Re: [ANNOUNCE] System Inactivity Monitor v1.0

[Alessandro Di Marco <dmr@gmx.it>]

Vojtech Pavlik <vojtech@suse.cz> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/