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
> dr
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
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 sus
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.
>>
>>
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
> ar
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
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 sai
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 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 inac
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
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. Examp
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?
> >
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
"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 us
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 definiti
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 momen
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
"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 d
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 dae
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?
>
> hmm
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,
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. Nonethe
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. Real
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 p
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 f
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 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 cou
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
>> grab
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
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 amoun
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 u
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 11:
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 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 acpi
42 matches
Mail list logo
