Previously James Simmons wrote:
> DBUS isthe future. I just wish they had programing howto for the average
> joe to write apps for it.
The docs are good enough in my experience, there just seems to be a gap
between the docs and the code. Strangely enough in this case there are
documented API bit
Previously Nigel Cunningham wrote:
> Looks like some work has already been done on getting kernel events out
> to dbus, too. Found this email:
> http://mail.gnome.org/archives/utopia-list/2004-July/msg00031.html
Or http://lists.freedesktop.org/archives/dbus/2005-February/002170.html
or one of the
> > > > Checkout DBUS. Its very nice.
> > >
> > > D-BUS is already userspace. netlink however is a nice transport system
> > > and there are several existing tools that pass messages from netlink
> > > onto D-BUS.
> >
> > That is what I mean. We already have a userspace component.
>
> I like t
On Tue, 2005-02-22 at 08:37, James Simmons wrote:
> > Previously James Simmons wrote:
> > > Checkout DBUS. Its very nice.
> >
> > D-BUS is already userspace. netlink however is a nice transport system
> > and there are several existing tools that pass messages from netlink
> > onto D-BUS.
>
> Th
> Previously James Simmons wrote:
> > Checkout DBUS. Its very nice.
>
> D-BUS is already userspace. netlink however is a nice transport system
> and there are several existing tools that pass messages from netlink
> onto D-BUS.
That is what I mean. We already have a userspace component.
-
To u
Previously James Simmons wrote:
> Checkout DBUS. Its very nice.
D-BUS is already userspace. netlink however is a nice transport system
and there are several existing tools that pass messages from netlink
onto D-BUS.
Wichert.
--
Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make thing
> > What is the benefit of splitting the flow of information so?
>
> It's split already. You get some from input (power and sleep keys on
> keyboards, sound volume keys and display brightness on some notebooks),
> some from ACPI events (power keys on notebooks and desktop cases, sound
> volume, d
> > I think we need a generic way of delivering system status changes to
> > userspace. Something like acpid but bigger than that, something not
> > so heavily oriented on ACPI. I wonder if that kernel connector patch
> > should be looked at.
>
> Absolutely. I've been thinking about this too, but
Hi!
> > I believe power and suspend keys should definitely go through
> > input. I'm not that sure about battery... Lid is somewhere in
> > between...
> >
>
> I think we need a generic way of delivering system status changes to
> userspace. Something like acpid but bigger than that, something not
Hi!
> > > The question is how to unify it.
> > >
> > > Using power.c to simply pass power/sleep keys to the ACPI event pipe
> > > could get the input subsystem out of the loop at least. Maybe we could
> > > even pass sound keys to it.
> >
> > I do not think passing sound keys through acpi is go
Hi.
On Sat, 2005-02-19 at 17:53, Dmitry Torokhov wrote:
> Hi Nigel,
>
> On Saturday 19 February 2005 01:28, Nigel Cunningham wrote:
> > Hi.
> >
> > On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote:
> > > On Friday 18 February 2005 18:31, Pavel Machek wrote:
> > > > I believe power and suspend
Hi Nigel,
On Saturday 19 February 2005 01:28, Nigel Cunningham wrote:
> Hi.
>
> On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote:
> > On Friday 18 February 2005 18:31, Pavel Machek wrote:
> > > I believe power and suspend keys should definitely go through
> > > input. I'm not that sure about b
Hi.
On Sat, 2005-02-19 at 13:58, Dmitry Torokhov wrote:
> On Friday 18 February 2005 18:31, Pavel Machek wrote:
> > I believe power and suspend keys should definitely go through
> > input. I'm not that sure about battery... Lid is somewhere in
> > between...
> I think we need a generic way of del
On Friday 18 February 2005 18:31, Pavel Machek wrote:
> Hi!
>
> > > What is the benefit of splitting the flow of information so?
> >
> > It's split already. You get some from input (power and sleep keys on
> > keyboards, sound volume keys and display brightness on some notebooks),
> > some from A
Le samedi 19 février 2005 à 00:51 +0100, Oliver Neukum a écrit :
> > Well, we can say that userspace definitely is interested in "power"
> > key ;-).
>
> I wouldn't call that selfevident. The system might be eg. a ticket
> vending system and we care only about wake ups from touchscreen,
> trackba
Hi!
> > If usb keyboard has power button... I do not think we really want to
> > route that through acpi. And what if acpi is not available? (APM knows
> > about suspend key in weird way, but not about power key).
>
> I'd suggest to primarily care about acpi. The other important power
> managemen
Am Samstag, 19. Februar 2005 00:34 schrieb Pavel Machek:
> Hi!
>
> > > Well, if you have power button on usb keyboard -- why should it be
> > > handled differently from built-in button?
> >
> > I see no reason. But that tells you that one subsystem should handle
> > that, not which subsystem.
>
Hi!
> > Well, if you have power button on usb keyboard -- why should it be
> > handled differently from built-in button?
>
> I see no reason. But that tells you that one subsystem should handle
> that, not which subsystem.
If usb keyboard has power button... I do not think we really want to
rout
Hi!
> > What is the benefit of splitting the flow of information so?
>
> It's split already. You get some from input (power and sleep keys on
> keyboards, sound volume keys and display brightness on some notebooks),
> some from ACPI events (power keys on notebooks and desktop cases, sound
> volum
Am Freitag, 18. Februar 2005 22:34 schrieb Pavel Machek:
> Well, if you have power button on usb keyboard -- why should it be
> handled differently from built-in button?
I see no reason. But that tells you that one subsystem should handle
that, not which subsystem.
> > > I think that's all you
Hi!
> > I wouldn't want to pass all the battery info (UPSes can be even more
> > complex, able to switch on/off individual sockets, etc) through input,
> > just the basic events:
> >
> > AC power on/off
> > battery full/normal/low/critical/(fail)
> >
> > Then the other power-related even
On Fri, Feb 18, 2005 at 10:23:19PM +0100, Oliver Neukum wrote:
> What is the benefit of splitting the flow of information so?
It's split already. You get some from input (power and sleep keys on
keyboards, sound volume keys and display brightness on some notebooks),
some from ACPI events (power k
> All you'd need is input.c. One file, approx 750 lines at the moment, a
> big chunk of that can be confugured out if you don't need procfs or
> hotplug.
>
> > Think about embedded stuff I wonder whether this is viable.
>
> On most embedded platforms you have some buttons or controls, so it's
>
Am Freitag, 18. Februar 2005 21:40 schrieb Vojtech Pavlik:
> I wouldn't want to pass all the battery info (UPSes can be even more
> complex, able to switch on/off individual sockets, etc) through input,
> just the basic events:
>
> AC power on/off
> battery full/normal/low/critical/(f
Hi!
> > Well, I'm not sure if input layer is suitable for batteries... Modern
> > battery has quite a lot of parameters. It can tell you current
> > voltage, current capacity (either mAh or mWh), design capacity, last
> > capacity at full charge, current current, battery's estimate of run
> > time
On Fri, Feb 18, 2005 at 09:24:43PM +0100, Pavel Machek wrote:
> Hi!
>
> > > > > But input layer shoudl not be used as a generic transport. I mean
> > > > > battery low, docking requests, etc has nothing to do with input.
> > > >
> > > > Well, plugging in a power cord is a physical user action muc
Am Freitag, 18. Februar 2005 21:14 schrieb Pavel Machek:
> Hi!
>
> > > > Yes, there are. They can probably stay... Or we can get "battery low"
> > > > key.
> > >
> > > We even have an event class for that, EV_PWR in the input subsystem.
> >
> > Over that route we'd arrive at a situation where p
Hi!
> > > > But input layer shoudl not be used as a generic transport. I mean
> > > > battery low, docking requests, etc has nothing to do with input.
> > >
> > > Well, plugging in a power cord is a physical user action much like
> > > closing the lid is, much like pressing the power button is, m
Hi!
> > > Yes, there are. They can probably stay... Or we can get "battery low"
> > > key.
> >
> > We even have an event class for that, EV_PWR in the input subsystem.
>
> Over that route we'd arrive at a situation where power management
> without the input layer is impossible. Think about embe
On Fri, Feb 18, 2005 at 02:20:13PM -0500, Dmitry Torokhov wrote:
> > > But input layer shoudl not be used as a generic transport. I mean
> > > battery low, docking requests, etc has nothing to do with input.
> >
> > Well, plugging in a power cord is a physical user action much like
> > closing th
On Fri, 18 Feb 2005 19:39:36 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 18, 2005 at 01:19:08PM -0500, Dmitry Torokhov wrote:
> > On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <[EMAIL PROTECTED]>
> > wrote:
> > > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
On Fri, Feb 18, 2005 at 01:19:08PM -0500, Dmitry Torokhov wrote:
> On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
> >
> > > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
> >
On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
>
> > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
> > > > and it will not work on i386/APM, anyway. I still believe right
> > >
On Fri, Feb 18, 2005 at 06:05:12PM +0100, Oliver Neukum wrote:
> Am Freitag, 18. Februar 2005 18:00 schrieb Vojtech Pavlik:
> > On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
> >
> > > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
> > > > > and it will not
Am Freitag, 18. Februar 2005 18:00 schrieb Vojtech Pavlik:
> On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
>
> > > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
> > > > and it will not work on i386/APM, anyway. I still believe right
> > > > solution is to a
On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
> > > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
> > > and it will not work on i386/APM, anyway. I still believe right
> > > solution is to add input interface to ACPI. /proc/acpi/events needs to
> > > die, bei
Hi!
> > It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
> > and it will not work on i386/APM, anyway. I still believe right
> > solution is to add input interface to ACPI. /proc/acpi/events needs to
> > die, being replaced by input subsystem.
>
> But aren't there power events
On Fri, 18 Feb 2005 14:26:51 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote:
> Hi!
>
>
> > >> > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
> > >> > this option.
> > >>
> > >> That was written a long time ago before the new power management went
> > >> in.
> > >> On PDA's
Pavel Machek:
It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
and it will not work on i386/APM, anyway. I still believe right
solution is to add input interface to ACPI. /proc/acpi/events needs to
die, being replaced by input subsystem.
I'm not too familiar with ACPI so I can't
> It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
> and it will not work on i386/APM, anyway. I still believe right
> solution is to add input interface to ACPI. /proc/acpi/events needs to
> die, being replaced by input subsystem.
But aren't there power events (battery low, e
Hi!
> >> > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
> >> > this option.
> >>
> >> That was written a long time ago before the new power management went
> >> in.
> >> On PDA's there is a power button and suspend button. So this was a hook
> >> so that the input layer
> > In 2.6, drivers/input/power.c would only have been built if
> > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
> > this option.
>
> That was written a long time ago before the new power management went
> in.
> On PDA's there is a power button and suspend button. So this
Hi!
> > > In 2.6, drivers/input/power.c would only have been built if
> > > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
> > > this option.
> >
> > That was written a long time ago before the new power management went in.
> > On PDA's there is a power button and suspen
On Mon, Feb 14, 2005 at 06:04:03PM +, James Simmons wrote:
>
> > In 2.6, drivers/input/power.c would only have been built if
> > CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
> > this option.
>
> That was written a long time ago before the new power management went i
> In 2.6, drivers/input/power.c would only have been built if
> CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
> this option.
That was written a long time ago before the new power management went in.
On PDA's there is a power button and suspend button. So this was a hook
In 2.6, drivers/input/power.c would only have been built if
CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
this option.
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
46 matches
Mail list logo
