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
>
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
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
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.
>>
>>
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
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
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
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,
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,
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
>
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
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
On Sat, Jan 27, 2007 at 05:45:25PM +, 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
On Sat, Jan 27, 2007 at 05:45:25PM +, 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,
On Sat, Jan 27, 2007 at 05:45:25PM +, 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
Vojtech Pavlik [EMAIL PROTECTED] writes:
On Sat, Jan 27, 2007 at 05:45:25PM +, 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 :-)
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
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
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
On Sat, Jan 27, 2007 at 05:45:25PM +, 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
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
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
On Sat, Jan 27, 2007 at 05:45:25PM +, 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
Pavel Machek <[EMAIL PROTECTED]> writes:
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.
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...
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?
> >
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
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... :-/
Pavel Machek [EMAIL PROTECTED] writes:
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.
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
"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
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
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
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
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
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
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
Pavel Machek <[EMAIL PROTECTED]> writes:
> 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
Pavel Machek [EMAIL PROTECTED] writes:
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
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
"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
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
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?
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?
>
>
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
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.
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,
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.
Pavel Machek <[EMAIL PROTECTED]> writes:
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
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
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.
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
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
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
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,
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...
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?
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
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
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
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.
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.
Pavel Machek [EMAIL PROTECTED] writes:
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
Pavel Machek <[EMAIL PROTECTED]> writes:
> +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
Pavel Machek [EMAIL PROTECTED] writes:
+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
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
>>
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
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
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
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
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
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
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".
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
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
--- gentable 2007-01-19
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
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
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
--- gentable 2007-01-19
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
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.
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
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
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
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
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
84 matches
Mail list logo
