pbbuttons-users — Everything regarding pbbuttons' usage and develpment

Re: Problems with sleep support

[Matthias G. <mat...@us...>]

On Thu, 03 Nov 2005 18:27:39 -0600
Joe Chryst <jo...@ch...> wrote:

Hi, 

> I have been helping some people in the Ubuntu forums with sleep issues
> on their PowerBooks.  I was under the impression that all PowerBooks
> were supported with pbbuttonsd.  However the command: 'pbbcmd query
> TAG_SLEEPSUPPORTED' returns 0.

That's right. Pbbuttonsd indeed supports all PowerBooks but it is only
a user space daemon and needs support from the kernel to do certain
tasks. Sleep (suspend-to-RAM) is such a task. 

Sleep is done by the kernel and not all PowerBooks are fully supported
up to now. Mostly the video hardware is the problem and can't be
reinitalized after wakeup. Pbbuttonsd only triggers the kernel to put
the machine to sleep and on some machines the kernel reports that sleep
is not supported.
 
> I have looked at the devices and pmu - all seems to be in order.  Am I
> missing something?  What else could I look for?

No, you missed nothing. If sleep is not supported on your machine it will
only be a matter of time. Ben Herrenschmidt and all his kernel hacker
colleages do a brilliant job and sooner or later they find a way to get
it work. :-)

   Best Regards
     Matthias

Problems with sleep support

[Joe C. <jo...@ch...>]

I have been helping some people in the Ubuntu forums with sleep issues
on their PowerBooks.  I was under the impression that all PowerBooks
were supported with pbbuttonsd.  However the command: 'pbbcmd query
TAG_SLEEPSUPPORTED' returns 0.

I have looked at the devices and pmu - all seems to be in order.  Am I
missing something?  What else could I look for?

Thanks for your help.

-Joe

gtkpbbutons: user script execution on hardware event

[Olivier M. <sh...@ss...>]

Hi list !

I wrote a little patch agains gtkpbbuttons-0.6.8 to allow every
instance of gtkpbbuttons to call a script (or program) whenever a
hardware event occurs, but at user level (ie not run as root).

The most common example is calling xscreensaver-command -lock when the
laptop goes to sleep (the feature I actually wanted ;-) ). But this
patch is more generic and allows to react to any user event that
generates a popup.

A simple script is also provided and installed
in /usr/share/gtkpbbuttons.

To use it:

gtkpbbuttons -e /usr/share/gtkpbbuttons/gtkpbbuttons-event.sh

The script takes two mandatory arguments:
 * the event that occured (have a look at the case...esac in the script)
 * the value (relevant for volume, brightness,...).

And now my laptop locks my session when going to sleep ;)

-- 
Olivier Mehani <sh...@ss...>
PGP fingerprint: 3720 A1F7 1367 9FA3 C654 6DFB 6845 4071 E346 2FD1

Re: G-P-M on the wrong track?!

[David Z. <da...@fu...>]

Hi Matthias,

On Sun, 2005-10-16 at 12:26 +0200, Matthias Grimm wrote:
> Hi,
> Richard might not like to hear this but I think the G-P-M development
> is on the wrong track. It started with the aim to build a GUI for power
> management features. So far so good. But in the meantime it piles more
> and more power management functions and because it runs with user
> privileges and need someone to do the dirty work, clutters HAL with low
> level power management functions which it is not designed for.

"Dirty work"... Heh :-)

> 
> Continuing this path will cause a dilemma for the end user: He has to
> decide between a well working power management (for example on powerpc
> machines, see pbbuttons.sourceforge.net) and the gnome desktop, because
> G-P-M has the GUI he or she likes but the functionallity breaks all
> other power management concepts (daemons).

Slight confusion here - maybe it's because I work for a distributor
(though I think most people know that I'm not directly involved with
Fedora or RHEL work at the moment), but frankly if the user has to
*choose* between cryptic software like *pbbuttons*, *hal*, *gpm*, GNOME,
KDE or whatever you've already lost. 

Like it or not, but the days of "hey, let's configure my own L33t
distro" are gone as I see it. Assembling a Linux-based distribution is
difficult with all the features users require today - if you look around
you'll see a lot of small distros struggling to "get it right" and even
the larger players are having a hard time too.

I think that most people *seriously underestimate* the cost of adding
yet another system level daemon that has to communicate with other
daemons. It's just plain crazy. Especially when we have the framework in
HAL to have this is one place. 

If you didn't know, there's an IHV angle too; if I produce laptops I
don't need to go to 7 different open source projects to get my patches
in. I don't need to convince my e.g. top-3 distros to patch 7 different
packages. I don't need to deal with 7 different bug trackers. I need to
do only 1/7 of all that. Think about it.

> I would like to suggest a slightly change of project aims:
> 
> 1. HAL
> The HAL specifications tells that HAL provides a view and detailed
> metadata to attached hardware, not more. Not a word about building the
> mega-system-do-everything daemon.
> 
> Please return to this aim. Limit HAL's functionallity to collect data
> from various sources and provide it to the desktop for visualisation.
> According to the specification it is not HAL's task to actively control
> certain hardware or start scripts because of desktop programs wanted so.

The purpose of HAL is to abstract hardware and provide a simply, secure
and yet powerful API.

I believe we now have achieved both the "reporting about hardware and
fix up crappy hardware / crappy kernel-side support" goal as well as
having the groundwork for the things you are concerned about:
interacting with hardware. 

For the latter, we have a simple and extensible framework for adding
methods to device objects. And it's proven. We've been using this in
Fedora Rawhide (which has a significant amount of users) for some time -
I believe other distros too.

> 2. G-P-M (Desktop Part)
> The G-P-M project description on gnomefiles.org sais: "The main focus
> here is the user interface; e.g. allowing configuration of power
> management from the desktop in a sane way"
> 
> This is exactly what G-P-M on the Desktop should do. Visualize data
> provided by HAL and comunicate with a power management daemon through
> dbus, but don't perform any power management functions by itself.

You overestimate how complicated power management should be. Really,
look at the interface HAL provides

 Suspend()              # put the system into low power mode
 Hibernate()            # suspend to disk
 SetLowPowermode(bool)  # called when transitioning to/from AC

and that's it. Note also we have hooks for different distros to plug in
their implementation for they want to suspend. That's it. Maybe we'll
add some selective suspend features to specific devices at some point
but I doubt it. Maybe we'll add some methods to control laptop displays.
But that's about it.

Oh, we also report about hardware like special laptop buttons but I
assume that you are not unhappy about that. If you are, I'd be happy to
address your concerns.

Btw, it is my view that anything else related to power management should
be handled in-kernel, e.g. run time power-management (dynamically
adjusting power management of certain devices, e.g. suspend a USB
thumbdrive using USB PM).

> 3. The Power Management Daemon
> Power management is too critical to lay it in user's hands. It is an
> important system feature and must be handled by a system daemon running
> with high privileges. No desktop program is able to fulfil this task.

You seem to confuse two things here

 1. Selecting policy - that is the task of g-p-m, e.g. knowing when to
    put the system into suspend. g-p-m cooperates with e.g. the X server
    and e.g. gnome-screen-saver to decide this. Obviously you want to
    read the users settings too. Hence all this needs to run in the
    desktop session.

 2. Enforcing policy - actually doing the suspend. Here HAL simply
    dispatches e.g. the Suspend() method call to a (vendor provided)
    script and returns.

I cannot believe that this thread has gotten so big about something as
petty and trivial as HAL offering *three* method calls to applications
like g-p-m. What's the real issue here?

About the concerns that people have that HAL is growing into a
mega-daemon that does everything - well; the only thing I can say is
that we're not going to add stupid method calls for just anything - we
want to be careful about what to add.

    Best,
    David

Re: G-P-M on the wrong track?!

[Danny K. <dan...@we...>]

On Monday 17 October 2005 14:42, you wrote:
> > This is what we do with powersave [1] on SUSE and ALT Linux. There is a
> > (desktop and arch (ix86, ix86_64, ia64 and now also ppc) independent)
> > daemon which only do powermanagement and which also do powermanagement if
> > there is no desktop user logged in.
>
> What use case has this got? How many times on battery do you leave your
> laptop at the login screen? There was talk of integrating g-p-m with gpm
> so that it runs at the login prompt (with the preferences of root), but
> I'm not sure how far this idea actually got.

This is a needed feature. There are not only laptops on battery. This was only 
one example. Other expample: You run you laptop on AC or your desktop machine 
and want to suspend or change cpufreq or set a special powerscheme as 
user/root without login to desktop. There are many possible use cases. We 
know this requirement from develop powersave and SUSE users since the start 
of the project. There are also several user which want to use the daemon 
without login from a script and also this work well with powersave.

And last but not least: there is not only GNOME and g-p-m. Why reimplement a 
system basic service for each desktop system. With a powermanagement daemon I 
can Implement hundreds of different clients for what ever desktop I want. 
(and IMO we need a own daemon for this and not HAL)

Btw. note powersave is only one example, This is a general design discussion. 

> > On the other side there are clients (e.g.
> > KPowersave/wmpowersave, see e.g. [2]) which communicate with the daemon
> > over DBUS to get information, change settings and suspend/standby the
> > machine.
>
> PowerSave is good, but doesn't provide support for (I might be wrong
> here) PowerMacs, UPS's, wireless mice and keyboards...

What mean you special with PowerMac? (k)powersave should also support PPC. 

Yes currently we don't support UPS and wireless mice/keyboards (IMO mice and 
keyboard is not really a powermanagement issue, but this is only my opinion), 
but only because this is currently not implemented this mean not we would not 
implement this. powersave is not feature freeze, we permanently enchance 
powersave and KPowersave. And if requested by the users, this could be one of 
the next issues.

> Isn't configuration actually done in /etc/sysconfig/powersave/?

Yes, but me make this configurable soon, since this was requested from a 
debian maintainer and from some users of other distributions (Gentoo, RH, 
Slackware ...).

> Seeing stuff like this in script files doesn't aspire me..
>
> elif [ $VAL -eq 81 ]; then # Start Browser/Konqueror
>   run_on_xserver "export DISPLAY=:0.0;/opt/kde3/bin/kfmclient
> openProfile webbrowsing" &
>   : # do something

This is from contrib dir and is not a supported user script. This is not part 
of the daemon at all. (IMO this is send from a powersave user and we collect 
such scripts in the CVS.) Btw. this is hotkey stuff and IMO o.k. if the user 
want use this.

> Plus, powersave is actually using HAL for some power=management
> functionality:
[...]
> So I'm rather confused.

Why confuced? I never ever sad we don't use HAL to get some information (and 
only to get information), but you can compile powersave also without HAL and 
this work also fine.

> > I see also the problem with currently unclear concept of HAL and to build
> > blackhole-'mega-system-do-everything daemon' (as I sad in different
> > discussions before).
>
> Yes I agree with that, but what about for UPS's... APC has one
> interface, Belkin have another. Two small addons just to update the
> charge seems better than one super init script just for everything.

I never sad that it not make sense to have addons to read/collect usefull 
information and provide them in HAL.

> > We should not workaround all problems for broken
> > hardware in HAL (e.g. we should not at special workarounds for broken
> > ACPI bios as for COMPAQ EVO N160), this is to much and IMO a problem to
> > maintain. Do such things in the kernel or in other ways.
>
> You ever got the kernel guys to accept fixes for a broken ACPI BIOS?
> The answer I got was that battery reporting fixes should be done in
> userspace when possible.

Yes we fix ACPI bugs if really needed (and if not posssible to workaround in 
userspace) in kernel, but this depends on the problem and is maybe easier for 
a distribution as for only one user. 

In the case of the COMPAQ we would first try to check if the DSDT is broken or 
if a BIOS update is available (this is the first way). And if it make sense 
we can workaround this also in the powersave daemon.
 
> > On the other side, there are also some issues which make IMO sense to set
> > devices with HAL where it not make sense to develop a additonal daemon.
>
> Like..? Also how do we know when to launch the additional daemon(s)?

One example: If you only need a simple command to enable a device (e.g. a 
tablet of a Tablet PC), which could easy detect with HAL, we should use HAL 
to do this. If you need no bigger infrastructure you could add a little addon 
to HAL. And if the user like to run HAL without root privileges, this is also 
no problem, he must maybe only live without the feature.

> > In case of powermanagement and ACPI (and also for input abstaction, see
> > IAL), I think it make sense to have a (or more different, what ever the
> > user/distibutor want) special daemon which only do powermanagement issues
> > (and maybe read informations from HAL about hardware, as we do with
> > powersave). In this daemon you can concentrate on all related problems
> > and workaround problems on a better way than HAL.
>
> But HAL works well now. 

This is a generall discussion. If you add e.g. for each broken bios a 
workaround to HAL, this is no longer easy to maintain and handle. In this 
case HAL is maybe sometime no longer work well. And this is only one example.

> There are lots of users who install g-p-m and 
> things "just work" -- no installing or starting of additional services,
> devices just working, accurate information.

If you install (K)powerssave this also work perfect with a daemon which do all 
powersave things (without to install additional packages). ;-)

> Using HAL as the backing store makes it easy for applications such as
> battstat applet have a really easy source for getting the data.

To read known information it's o.k. for me. But you could read this 
information (and additional do all other related things) also easy from a 
special daemon over DBUS. What's the problem?

> HAL is already used in lots of GNOME applications and the new dep not a
> problem for most people.

? To read information: o.k. But are there so many apps which use the 
powermanagement part (suspend, powersave ...) of HAL ? I'm not complete sure 
but e.g. on SUSE there is no tool.

Cheers,

Danny

Re: G-P-M on the wrong track?!

[Richard H. <hug...@gm...>]

On Sun, 2005-10-16 at 14:09 -0400, John (J5) Palmieri wrote:
> 
> This is how it should work.  If the ACPI layer is the only one written
> right now you would just need to write a PMU layer.

There is complete support for APM and basic support for PMU.

Richard.

Re: G-P-M on the wrong track?!

[Danny K. <dan...@we...>]

On Sunday 16 October 2005 12:26, Matthias Grimm wrote:
> Divide G-P-M in two parts (projects):
>  part 1: Desktop module which visualize interesting data to the user
>          including configuration dialogs
>  part 2: a power management daemon that do the dirty work, provide data
>          to HAL and receive orders from desktop programs through dbus.
>
> This concept has a lot of advantages:
>  - It won't break with existing power management structures. Migration
>    is possible in small steps,
>  - The user can use the Desktop tools with a power manager he likes,
>  - the new power management daemon will cooperate with all desktops,
>    not only with Gnome,
>  - HAL can fulfill its job straight forward. No foreign code anymore.

This is what we do with powersave [1] on SUSE and ALT Linux. There is a 
(desktop and arch (ix86, ix86_64, ia64 and now also ppc) independent) daemon 
which only do powermanagement and which also do powermanagement if there is 
no desktop user logged in. On the other side there are clients (e.g. 
KPowersave/wmpowersave, see e.g. [2]) which communicate with the daemon over 
DBUS to get information, change settings and suspend/standby the machine.

I see also the problem with currently unclear concept of HAL and to build 
blackhole-'mega-system-do-everything daemon' (as I sad in different 
discussions before). We should not workaround all problems for broken 
hardware in HAL (e.g. we should not at special workarounds for broken ACPI 
bios as for COMPAQ EVO N160), this is to much and IMO a problem to maintain. 
Do such things in the kernel or in other ways. 

On the other side, there are also some issues which make IMO sense to set 
devices with HAL where it not make sense to develop a additonal daemon.

In case of powermanagement and ACPI (and also for input abstaction, see IAL), 
I think it make sense to have a (or more different, what ever the 
user/distibutor want) special daemon which only do powermanagement issues 
(and maybe read informations from HAL about hardware, as we do with 
powersave). In this daemon you can concentrate on all related problems and 
workaround problems on a better way than HAL.

I agree your comments.

Cheers,

Danny

[1] http://sourceforge.net/projects/powersave/
[2] http://freshmeat.net/projects/kpowersave

Re: G-P-M on the wrong track?!

[Danny K. <dan...@we...>]

On Sunday 16 October 2005 18:02, Matthias Grimm wrote:
[...]
> You already split up g-p-m in two parts. One part becomes
> the desktop part and everything else, you can't do without root
> permissions, you graft on HAL. I thinks that is not very fair ;-) You
> have still a daemon and a desktop application. Think about it.

Same for me, this is the concept with powersave/kpowersave ;-)

[...]
> This approach reaches to short. your design expects that a user is
> logged  in in X11, running gnome and gnome-screensaver to stick with
> your example above. But you can't expect all people to work this way.
>
> For instance I never use a screensaver. Nevertheless would g-p-m get
> the idle information? 

IMO you could get this information with little code from X11 server.

> Other users remotely log into their laptop and 
> expect that the power management will recognise this and allow working
> even with closed lid. There are thousand methods people will use their
> computer and the powermanagement must support them all.

see powersave ;-) , you need also a solution if nobody is logged in. For 
example: what happens if nobody is logged in and the battery gets empty? If 
you have a daemon: shutdown or suspend if a defined battery fill will 
reached.

> And beside the simple suspend-to-ram example the daemon must handle much
> more complex tasks such as controlling the LCD brightness depending on
> an ambient light sensor, which raw signal is influenced by current the
> LCD brightness and must be compensated before usage. Those and much more
> tasks have to be implemented in HAL. Do you really think this makes
> sense? Wouldn't it be better to put those functions in an seperate power
> management daemon?

agree

[...]
> > HAL does that job now. In KDE4 HAL plays a more prominent role.
>
> Yes, I'm sure. But they also need the policy agent like g-p-m, for the
> intelligence, don't they? They could use an independent power management
> daemon without change but this is more the matter of distributors than
> of desktop systems. The KDE people always have to implement the
> configuration stuff themselves because of the Desktop Look&Feel but
> don't have to care about policies and methods.

agree

[...]

Cheers,

Danny

Re: G-P-M on the wrong track?!

[Danny K. <dan...@we...>]

On Sunday 16 October 2005 18:04, Matthias Grimm wrote:
[...]
> > Also putting all the ACPI data in HAL has let us fix *many* broken
> > BIOS's, so that any userspace application doesn't have to care about
> > the specific details. I know its not such an issue for the PMU laptops
> > out there, but ACPI is broken more of the time than working.
>
> Is this the way to go? The kernel has already an ACPI interface in /proc
> and can handle broken BIOSs much better than HAL can. Repairing of
> broken BIOSs is not the task of HAL.

IMO you are right. This is a task for kernel, hardware producer (to fix bios) 
or/and a special powermanagment daemon.

> I think a better solution would be, and I'm quite sure you meant it
> that way, to define schemas for certain elements (like batteries) in HAL
> and fill the data (level, max charge, etc. Whatever is nedded to show
> useful data in a battery monitor on the desktop) nevertheless where the
> data come from (ACPI, APM, PMU or any daemon).

right, you can also fill information for broken bios in HAL with/from a other 
(powermanagement) damon. 

> > What's the point? That limits hal to being a flashy version of lspci
> > and lsusb when it has *so much more* potential.
>
> Partly yes partly no. HAL shouldn't mirror /proc and /sys but provide
> filtered information for desktop applications.
>
> > David Zeuthen (HAL maintainer) seemed happy with my changes, and I've
> > got no reason to think that he's not okay with the direction HAL has
> > taken. (David, speak up if you have!)
>
> This is not a matter of "making someone happy". I would be happy too,
> if you sent so many patches for pbbuttonsd to me :-)
>
> HAL is going to become an essential part of GNU/Linux desktop systems
> and therefore is must reach an stable state very soon. Application
> programmer must be able to rely on its API and feature set. More
> important than adding new features would be to define the data scheme
> for certain elements so that daemon programmer could fill and desktop
> application programmers could use them.

Yes, we need a more actual and stable API for HAL. We should discuss more 
about this issue and we need to update the specification which is currently 
in many parts out of date and not in sync with the code.

[...]

Cheers,

Danny

Re: G-P-M on the wrong track?!

[Danny K. <dan...@we...>]

On Monday 17 October 2005 10:24, Martin Pitt wrote:
> Hal can currently run perfectly without root privileges, 

IMO this is not correct. Please take a look at the difference between detected 
devices with and without --retain-privileges option (in my case e.g. 60 
devices without privileges and 71 with). There are also different 
information/keys missing if HAL not run as root daemon. 

But this is IMO a personal taste. 

> and it should 
> stay that way. Every task that requires root privileges belongs into a
> separate program (which might be a daemon, or dbus service) that is
> small, specific, can be audited, and has a clearly defined an minimal
> interface to the user.

General I agree (specially for such big 	subject area as powermanagement), but 
there are also some little problems where it maybe make sense to have a HAL 
addon to set some propertys for devices to prevent develop a damon only to 
set one property.

> So please keep the current design of hal and resist the temptation to
> include active elements into it. You will sacrifice both security and
> flexibility.

see above.

Cheers,

Danny

Re: G-P-M on the wrong track?!

[John (J. P. <jo...@re...>]

On Sun, 2005-10-16 at 18:04 +0200, Matthias Grimm wrote:
> On Sun, 16 Oct 2005 12:41:26 +0100
> Richard Hughes <hug...@gm...> wrote:
> 
> Hi,
> I split the mail up in three parts, so it keeps readable :-)
> 
> HAL
> -----
> I think the main focus of HAL is to collect data that is helpful for
> desktop applications to inform the desktop user. For example to create
> fitting symbols for newly attached devices, to name those symbols with
> names the user understands (QuickPix USB Camera instead of /dev/sda)
> or the current battery level. Up to here I think we aggree because your
> examples show exact this usage of HAL.

While HAL was indeed conceived by desktop hackers it is actually not
desktop centric.  The real idea for it is to be a one stop store for all
types of applications which abstracts the underlying system away.  It is
a bridge between kernel space and user space which gives a more
consistent view of hardware than different kernels care to.

> My point here is: Where do you draw the border line? Hardware
> Abstraction Layer is a highbrow name but HAL can't never be a real
> hardware abstraction layer. File operation to a hard drive will never go
> through HAL, Sound files will never be played through HAL, Documents
> will never be printed through HAL. 

We went through this many times back when HAL was still in its infancy.
We understood in the end to make HAL useful and accepted it need to
become more of a Hardware Enumeration Layer instead of your traditional
HAL, we however did not specifically say it could not take on a couple
of specialized tasks.  To that end HAL exports policies and calls
callbacks and does a number of other functional thing we though benefit
from abstraction.  While your examples are things we would never do with
HAL, for things like power management it makes sense to allow for
functionality to be called from HAL.

> There are special API's and
> abstraction layers out for this tasks (Kernel, CUPS, ALSA, OSS, etc).
> The HAL specification pointed this out too with a nice graphics: You get
> all necessary information from HAL but talk then to the device directly.

In some cases yes but you are oversimplifying the issues.  For instance
we are not always guaranteed to be running on a Linux Kernel.  

> > Also putting all the ACPI data in HAL has let us fix *many* broken
> > BIOS's, so that any userspace application doesn't have to care about
> > the specific details. I know its not such an issue for the PMU laptops
> > out there, but ACPI is broken more of the time than working.
> 
> Is this the way to go? The kernel has already an ACPI interface in /proc
> and can handle broken BIOSs much better than HAL can. Repairing of
> broken BIOSs is not the task of HAL.

But this is what HAL does.  It culls the info from /proc and other
sources.  On Solaris they are hooking into their framework.

> I think a better solution would be, and I'm quite sure you meant it
> that way, to define schemas for certain elements (like batteries) in HAL
> and fill the data (level, max charge, etc. Whatever is nedded to show
> useful data in a battery monitor on the desktop) nevertheless where the
> data come from (ACPI, APM, PMU or any daemon).

This is how it should work.  If the ACPI layer is the only one written
right now you would just need to write a PMU layer.

> > What's the point? That limits hal to being a flashy version of lspci
> > and lsusb when it has *so much more* potential.
> 
> Partly yes partly no. HAL shouldn't mirror /proc and /sys but provide
> filtered information for desktop applications.

See my first point about the desktop.  The problem with /proc and /sys
is the info is never in a standard format.  I mean look at what has been
accomplished because we added a standard interface.

> > David Zeuthen (HAL maintainer) seemed happy with my changes, and I've
> > got no reason to think that he's not okay with the direction HAL has
> > taken. (David, speak up if you have!)
> 
> This is not a matter of "making someone happy". I would be happy too,
> if you sent so many patches for pbbuttonsd to me :-)
> 
> HAL is going to become an essential part of GNU/Linux desktop systems
> and therefore is must reach an stable state very soon. Application
> programmer must be able to rely on its API and feature set. More
> important than adding new features would be to define the data scheme
> for certain elements so that daemon programmer could fill and desktop
> application programmers could use them.

It is a case by case basis thing.  HAL is pretty stable as is.

-- 
John (J5) Palmieri <jo...@re...>

Re: G-P-M on the wrong track?!

[John (J. P. <jo...@re...>]

Eak! I would rather have this stuff as part of an addon to HAL.  Really
plugin or daemon, they are the same thing.  HAL then adds a nice
interface on top.  As for signals you can just listen for a property
changed in HAL.  Come to think of it I might just move my printer
configuration stuff to HAL in Fedora.

Network Manager itself as a separate daemon makes sense because of the
complexity.  Power Management is really not all that complex that it
warrants a separate daemon.  

On Sun, 2005-10-16 at 18:03 +0200, Matthias Grimm wrote:
> On Sun, 16 Oct 2005 12:41:26 +0100
> Richard Hughes <hug...@gm...> wrote:
> 
> Hi,
> Part II of the split up mega mail :-)
> 
> DBus
> ------
> > Yes it breaks concepts. It uses DBUS to lock down who can do what, so
> > that the default desktop user doesn't have to enter a root password to
> > change a hibernation setting.
> 
> DBus is out of discussion here. I know that a communication path between
> processes is needed and dbus seems to be the choice. So I have no
> problem with dbus.
> 
> > HAL doesn't "do everything" -- it now provides a sane abstraction for
> > devices (in my opinion). You can call SetLCDBrightness on a LCD panel
> > device, or Suspend on the Computer device, but that's about it for the
> > scope of methods.
> 
> This could be much better done with dbus than with HAL. Why don't we
> define a SetLCDBrightness Signal and broadcast it to interested servers?
> Dbus is also some type of abstraction layer but this approach fits
> better to the HAL dogma: Get information from HAL but talk with the
> device/daemon directly.
> 
> > The beauty of using HAL addons is that the acpi method is only run for
> > acpi systems, the csr addon is only for wireless battery and mouse
> > etc. You do not have to start one system service like apmd, or acpid
> > or pmud on install, HAL will start the correct addon(s) automatically
> > depending on your hardware.
> 
> Every power management daemon could do the same.
> 
>  Best Regards
>    Matthias
> _______________________________________________
> hal mailing list
> ha...@li...
> http://lists.freedesktop.org/mailman/listinfo/hal
-- 
John (J5) Palmieri <jo...@re...>

Re: pbbuttonsd bug?

[Matthias G. <mat...@us...>]

On Sun, 16 Oct 2005 15:47:13 +0200
Gabriel Labelle <gla...@op...> wrote:

> Please check out the following:
> 
> http://bugzilla.ubuntu.com/show_bug.cgi?id=17903

I don't think this is a pbbuttonsd problem, but maybe it could help.

> On system startup everything is OK and when I close my powerbook G4's
> lid it goes to sleep like a baby :)

Pbbuttonsd work ends here

> But when I open the powerbook's lid to start working again:

> 1) Each of my USB storage devices (External HDD, mobile phone and
> iPod) are present twice in gnome (nautilus).

This seems to be a problem of the usb driver or maybe hotplug. The USB
Controller will be powered up again and maybe sends hotplug events for
every connected device again?

> 2) I loose internet connectivity of my ath_pci device. I need to
> remove the pcmcia card, put it back in and "sudo ifup ath0" to get
> connectivity again. The card is a Netgear WG511T (Atheros
> Communications,  Inc. AR5212 802.11abg NIC (rev 01)).

The PCMCIA card might cause problems with suspend to ram. I never heard
of a case but there is a script from old days that disables the PCMCIA
card before going to sleep. Check /etc/power/scripts.d/pcmcia.

 Best Regards
   Matthias

Re: G-P-M on the wrong track?!

[Matthias G. <mat...@us...>]

On Sun, 16 Oct 2005 12:41:26 +0100
Richard Hughes <hug...@gm...> wrote:

Hi,
I split the mail up in three parts, so it keeps readable :-)

HAL
-----
I think the main focus of HAL is to collect data that is helpful for
desktop applications to inform the desktop user. For example to create
fitting symbols for newly attached devices, to name those symbols with
names the user understands (QuickPix USB Camera instead of /dev/sda)
or the current battery level. Up to here I think we aggree because your
examples show exact this usage of HAL.

My point here is: Where do you draw the border line? Hardware
Abstraction Layer is a highbrow name but HAL can't never be a real
hardware abstraction layer. File operation to a hard drive will never go
through HAL, Sound files will never be played through HAL, Documents
will never be printed through HAL. There are special API's and
abstraction layers out for this tasks (Kernel, CUPS, ALSA, OSS, etc).
The HAL specification pointed this out too with a nice graphics: You get
all necessary information from HAL but talk then to the device directly.

> Also putting all the ACPI data in HAL has let us fix *many* broken
> BIOS's, so that any userspace application doesn't have to care about
> the specific details. I know its not such an issue for the PMU laptops
> out there, but ACPI is broken more of the time than working.

Is this the way to go? The kernel has already an ACPI interface in /proc
and can handle broken BIOSs much better than HAL can. Repairing of
broken BIOSs is not the task of HAL.

I think a better solution would be, and I'm quite sure you meant it
that way, to define schemas for certain elements (like batteries) in HAL
and fill the data (level, max charge, etc. Whatever is nedded to show
useful data in a battery monitor on the desktop) nevertheless where the
data come from (ACPI, APM, PMU or any daemon).

> What's the point? That limits hal to being a flashy version of lspci
> and lsusb when it has *so much more* potential.

Partly yes partly no. HAL shouldn't mirror /proc and /sys but provide
filtered information for desktop applications.

> David Zeuthen (HAL maintainer) seemed happy with my changes, and I've
> got no reason to think that he's not okay with the direction HAL has
> taken. (David, speak up if you have!)

This is not a matter of "making someone happy". I would be happy too,
if you sent so many patches for pbbuttonsd to me :-)

HAL is going to become an essential part of GNU/Linux desktop systems
and therefore is must reach an stable state very soon. Application
programmer must be able to rely on its API and feature set. More
important than adding new features would be to define the data scheme
for certain elements so that daemon programmer could fill and desktop
application programmers could use them.

For example:
   battery {
     charge level
     max charge level
     temperature
     discharge cycle no.
     ...
   }

I think HAL don't need to get the data itself in most of the cases.

 Best Regards
   Matthias

Re: G-P-M on the wrong track?!

[Matthias G. <mat...@us...>]

On Sun, 16 Oct 2005 12:41:26 +0100
Richard Hughes <hug...@gm...> wrote:

Hi,
Part II of the split up mega mail :-)

DBus
------
> Yes it breaks concepts. It uses DBUS to lock down who can do what, so
> that the default desktop user doesn't have to enter a root password to
> change a hibernation setting.

DBus is out of discussion here. I know that a communication path between
processes is needed and dbus seems to be the choice. So I have no
problem with dbus.

> HAL doesn't "do everything" -- it now provides a sane abstraction for
> devices (in my opinion). You can call SetLCDBrightness on a LCD panel
> device, or Suspend on the Computer device, but that's about it for the
> scope of methods.

This could be much better done with dbus than with HAL. Why don't we
define a SetLCDBrightness Signal and broadcast it to interested servers?
Dbus is also some type of abstraction layer but this approach fits
better to the HAL dogma: Get information from HAL but talk with the
device/daemon directly.

> The beauty of using HAL addons is that the acpi method is only run for
> acpi systems, the csr addon is only for wireless battery and mouse
> etc. You do not have to start one system service like apmd, or acpid
> or pmud on install, HAL will start the correct addon(s) automatically
> depending on your hardware.

Every power management daemon could do the same.

 Best Regards
   Matthias

Re: G-P-M on the wrong track?!

[Matthias G. <mat...@us...>]

On Sun, 16 Oct 2005 12:41:26 +0100
Richard Hughes <hug...@gm...> wrote:

Hi,
and part III,

Power Manager
--------------------
> When I was designing g-p-m, I was going down the route that you
> explained. There was a system initscript that launched a daemon that
> spoke to HAL, and the daemon then spoke to g-p-m. This was so complex
> it was never going to work. Speaking to people, it became obvious to
> me (it was spelt out to me!) that this middle daemon was not required
> at all. The policy could be done in g-p-m as a user-session daemon.

You already split up g-p-m in two parts. One part becomes
the desktop part and everything else, you can't do without root
permissions, you graft on HAL. I thinks that is not very fair ;-) You
have still a daemon and a desktop application. Think about it.

> > Power management is too critical to lay it in user's hands. It is an
> > important system feature and must be handled by a system daemon
> > running with high privileges. No desktop program is able to fulfil
> > this task.
> 
> Why not? I'm a user, and I want to suspend my laptop after 10 minutes
> of inactivity. Assuming I'm logged in as a console user (i.e. sitting
> at the physical keyboard) I can set this to 10 minutes in g-p-p, and
> then g-p-m will use gnome-screensaver's information about my
> inactivity so that after 10 minutes, g-p-m tells HAL to suspend (hal
> calls the distro-specific scripts) and it "just works".

This approach reaches to short. your design expects that a user is
logged  in in X11, running gnome and gnome-screensaver to stick with
your example above. But you can't expect all people to work this way.

For instance I never use a screensaver. Nevertheless would g-p-m get
the idle information? Other users remotely log into their laptop and
expect that the power management will recognise this and allow working
even with closed lid. There are thousand methods people will use their
computer and the powermanagement must support them all.

And beside the simple suspend-to-ram example the daemon must handle much
more complex tasks such as controlling the LCD brightness depending on
an ambient light sensor, which raw signal is influenced by current the
LCD brightness and must be compensated before usage. Those and much more
tasks have to be implemented in HAL. Do you really think this makes
sense? Wouldn't it be better to put those functions in an seperate power
management daemon?

> >  part 2: a power management daemon that do the dirty work, provide
> >  data to HAL and receive orders from desktop programs through dbus.
 
> What "orders" would it take? What data does it provide? As soon as you
> start fleshing out the detail (i.e. formal design) it all gets
> horrendously complex.

Dbus signals to be defined as you defined the HAL API to set the LCD
brightness for instance. The design is not more complex as your current
approach. I already did something like this with pbbuttonsd and I'm sure
we are able to do it again, together. :-)
 
> > This concept has a lot of advantages:

> Why is that an advantage? On my system now, I can install g-p-m, a
> pretty recent HAL, and (potentially) remove:

[a whole bunch of daemons removed]

Yeah, it is always nice to get rid of some daemons :-) but you must not
forget that the programmers of this daemons had a problem to solve and
they focus only on that problem. They weren't interested in other
persons problems or in a generic solutions many people, even non
experienced users could use. As result this daemons didn't do very much.

Thats the doom of GNU/Linux: The hand-made scripts make the system
extremly flexible but unfathomable for normal users (that I am). Let us
find a middle way out of this dilemma.

> HAL does that job now. In KDE4 HAL plays a more prominent role.

Yes, I'm sure. But they also need the policy agent like g-p-m, for the
intelligence, don't they? They could use an independent power management
daemon without change but this is more the matter of distributors than
of desktop systems. The KDE people always have to implement the
configuration stuff themselves because of the Desktop Look&Feel but
don't have to care about policies and methods.

> > There are still a lot of questions to answer but I think this
> > concept is future proof and bring power management on Linux a step
> > forward. There are a lot of good ideas in G-P-M and a lot of highly
> > motivated and entusiastic people push it forward with breathtaking
> > speed
> 
> Urm... You trying to say I should get out more :-) I'm taking that as
> a compliment :-)

Yes, it is. :-) I would never despise someone else's work. All I want to
offer is ... lets say... some guidance ;-)

> There is a plan, but the plan keeps changing :-)

I see :-)

> > Also everything is eyed through the Gnome spectacles only but power
> > management is not a Gnome only issue.
> 
> Hence using HAL. HAL is cross platform and cross environment.

Sure, but we talk also about g-p-m here.

> > I have developed pbbuttons (power management daemon for Linus on
> > Apple
> > computers) for four years now and I would be pleased to join the
> > team
> > developing the new power management daemon I described above.
> 
> I've seen pbbuttons, and I'm quite impressed. There's lots of code
> that could be used by HAL directly (like the communicating with PMU),
> without the additional overheads of the another management daemon.

see above and in the mail regarding HAL.

> I don't want to be seen as obsoleting pbbuttons with g-p-m, as for
> powermac hardware, pbbuttons is by far generations ahead.

I wouldn't have a problem with this, if it is evolution, replace it with
something better, something more flexible. 

> The things is, pbbuttons is specific to PMU hardware which makes it
> unsuitable as a core GNOME application.

That's not true. PBButtons has a modular design and could also be used
on other platforms than powerpc. Only a low level ACPI module is
missing. There is some work in progress by a user but I don't know
exactly how far he is.

But that's not the point. Even I won't replace g-p-m with pbbuttonsd.
Furthermore I would like to combine the experience and knowledge of
both projects to create the generic power management architecture
everybody is dreaming of. Oh well ... or as close as possible to it :-)

 Best Regards
   Matthias

 

pbbuttonsd bug?

[Gabriel L. <gla...@op...>]

Please check out the following:

http://bugzilla.ubuntu.com/show_bug.cgi?id=17903

Many thanks for your time and help.

-- 
Gabriel Labelle <gla...@op...>

Re: G-P-M on the wrong track?!

[Richard H. <hug...@gm...>]

On Sun, 2005-10-16 at 12:26 +0200, Matthias Grimm wrote:
> Hi,
> Richard might not like to hear this but I think the G-P-M development
> is on the wrong track.

Criticism is always good. I know I'm enthusiastic but sometimes you need
to take a step back.

> It started with the aim to build a GUI for power
> management features. So far so good. But in the meantime it piles more
> and more power management functions and because it runs with user
> privileges and need someone to do the dirty work, clutters HAL with low
> level power management functions which it is not designed for.

Hmm, disagree here. HAL is used as a "Hardware Abstraction" daemon.

For example:

I want to get a UPS's charge. I search for all the battery objects with
type "ups"

I then use hal to get battery.percentage_charge

I want to get a laptop battery charge. I search for all battery objects
with type "primary"

I then use hal to get battery.percentage_charge

The same with wireless mice and keyboards.

You see? One abstracted interface using very different information
stores (serial, acpi, csr).

Also putting all the ACPI data in HAL has let us fix *many* broken
BIOS's, so that any userspace application doesn't have to care about the
specific details. I know its not such an issue for the PMU laptops out
there, but ACPI is broken more of the time than working.

> Continuing this path will cause a dilemma for the end user: He has to
> decide between a well working power management (for example on powerpc
> machines, see pbbuttons.sourceforge.net) and the gnome desktop, because
> G-P-M has the GUI he or she likes but the functionallity breaks all
> other power management concepts (daemons).

Yes it breaks concepts. It uses DBUS to lock down who can do what, so
that the default desktop user doesn't have to enter a root password to
change a hibernation setting.

I agree HAL support has not great support for powerpc at the moment, but
the basics are in place.

See http://gnome-power.sourceforge.net/powerbook.php for why.

> I would like to suggest a slightly change of project aims:
> 
> 1. HAL
> The HAL specifications tells that HAL provides a view and detailed
> metadata to attached hardware, not more. Not a word about building the
> mega-system-do-everything daemon.

Then what's the point in HAL? To provide a nice tree showing our PCI and
USB hardware? That's looking at HAL without an objective stance, I
imagine C++ where you can perform a method on an object, the same as
read it's properties. A lot more powerful than just reading in the
properties.

HAL doesn't "do everything" -- it now provides a sane abstraction for
devices (in my opinion). You can call SetLCDBrightness on a LCD panel
device, or Suspend on the Computer device, but that's about it for the
scope of methods.

The beauty of using HAL addons is that the acpi method is only run for
acpi systems, the csr addon is only for wireless battery and mouse etc.
You do not have to start one system service like apmd, or acpid or pmud
on install, HAL will start the correct addon(s) automatically depending
on your hardware.

> Please return to this aim. Limit HAL's functionallity to collect data
> from various sources and provide it to the desktop for visualisation.

What's the point? That limits hal to being a flashy version of lspci and
lsusb when it has *so much more* potential.

> According to the specification it is not HAL's task to actively control
> certain hardware or start scripts because of desktop programs wanted so.

I depends on what you define HAL as. I agree, HAL used to be more of a
"Hardware Reporting Daemon" and now it's more like true hardware
abstraction.

David Zeuthen (HAL maintainer) seemed happy with my changes, and I've
got no reason to think that he's not okay with the direction HAL has
taken. (David, speak up if you have!)

> 2. G-P-M (Desktop Part)
> The G-P-M project description on gnomefiles.org sais: "The main focus
> here is the user interface; e.g. allowing configuration of power
> management from the desktop in a sane way"

It is sane. No root passwords, no funky permissions files to change and
no detail about newbie-unfriendly concepts such as ACPI, PMU and APM.

> This is exactly what G-P-M on the Desktop should do. Visualize data
> provided by HAL and comunicate with a power management daemon through
> dbus, but don't perform any power management functions by itself.

When I was designing g-p-m, I was going down the route that you
explained. There was a system initscript that launched a daemon that
spoke to HAL, and the daemon then spoke to g-p-m. This was so complex it
was never going to work. Speaking to people, it became obvious to me (it
was spelt out to me!) that this middle daemon was not required at all.
The policy could be done in g-p-m as a user-session daemon.

Think about it. How many users do you have logged in to graphical
desktop environments on your laptop right now? For me it's one, so the
"session daemon controls the system" idea is valid. On a server with
multiple user logins, each with a DE, I don't expect to have g-p-m
installed (or running in each user session), as it's not required. And
even if it was installed it wouldn't work as the DBUS permissions are
locked down by default.

The permission structure is a lot like NetworkManager in this regard.

> 3. The Power Management Daemon
> Power management is too critical to lay it in user's hands. It is an
> important system feature and must be handled by a system daemon running
> with high privileges. No desktop program is able to fulfil this task.

Why not? I'm a user, and I want to suspend my laptop after 10 minutes of
inactivity. Assuming I'm logged in as a console user (i.e. sitting at
the physical keyboard) I can set this to 10 minutes in g-p-p, and then
g-p-m will use gnome-screensaver's information about my inactivity so
that after 10 minutes, g-p-m tells HAL to suspend (hal calls the
distro-specific scripts) and it "just works".

> Divide G-P-M in two parts (projects):
>  part 1: Desktop module which visualize interesting data to the user
>          including configuration dialogs
>  part 2: a power management daemon that do the dirty work, provide data
>          to HAL and receive orders from desktop programs through dbus.

What "orders" would it take? What data does it provide? As soon as you
start fleshing out the detail (i.e. formal design) it all gets
horrendously complex.

> This concept has a lot of advantages:
>  - It won't break with existing power management structures. Migration
>    is possible in small steps,

Why is that an advantage? On my system now, I can install g-p-m, a
pretty recent HAL, and (potentially) remove:

toshutils
apmd
acpid
apmd
pmud
ial
FnFX

And I can setup most typical actions in g-p-m. The old setups will still
work, there's nothing *forcing* you to use g-p-m over a custom perl
script that lives in /etc/acpi/events.d

Talking to real world users (i.e. proficient with power-management and
linux) they have intricate scripts written in perl, sh and some C that
do actions on a hardcoded events (and writing handlers for all their own
hardware). For a non-power user, /etc/acpi/events.d is a scary place.

>  - The user can use the Desktop tools with a power manager he likes,

Same as now. Talking to the KDE guys at LinuxWorld UK (we went out for
beers afterwards, no blood spilt...) they liked the idea of the HAL
information store for PM, and said it could be built into the existing
KDE framework (where they now talk directly to the ACPI and APM
hardware). They could switch to using HAL to do a suspend in a few lines
of code (and potentially remove *lots* of system specific code).

>  - the new power management daemon will cooperate with all desktops,
>    not only with Gnome,

HAL does that job now. In KDE4 HAL plays a more prominent role.

>  - HAL can fulfill its job straight forward. No foreign code anymore.

Depends on your definition of foreign. If you mean code that is a bit
different to the standard device stuff, then I think it has actually fit
in quite well.

> There are sill a lot of questions to answer but I think this concept is
> future proof and bring power management on Linux a step forward. There
> are a lot of good ideas in G-P-M and a lot of highly motivated and
> entusiastic people push it forward with breathtaking speed

Urm... You trying to say I should get out more :-) I'm taking that as a
compliment :-)

>  but it seems to me that the big plan is incomplete or missing at all.

There is a plan, but the plan keeps changing :-)
Like the kernel, if there's found a better way to do something then they
don't mind changing things (breaking compatibility) and upsetting
people. Just like the HAL LCD brightness API change.

> Also everything
> is eyed through the Gnome spectacles only but power management is not a
> Gnome only issue.

Hence using HAL. HAL is cross platform and cross environment.

> I have developed pbbuttons (power management daemon for Linus on Apple
> computers) for four years now and I would be pleased to join the team
> developing the new power management daemon I described above.

I've seen pbbuttons, and I'm quite impressed. There's lots of code that
could be used by HAL directly (like the communicating with PMU), without
the additional overheads of the another management daemon.

I don't want to be seen as obsoleting pbbuttons with g-p-m, as for
powermac hardware, pbbuttons is by far generations ahead. The things is,
pbbuttons is specific to PMU hardware which makes it unsuitable as a
core GNOME application. If you think as g-p-m as ACPI only (which is
could be) then the apple user experience is going to be vastly different
to the ACPI experience. I think we need to unify the many architectures
into a common entity. Which is why HAL is important.

> I'm awaiting your feedback.

Cheers for your email, I hope I've answered some of your questions and
worries. Sorry for the super long email.

Richard.

G-P-M on the wrong track?!

[Matthias G. <mat...@us...>]

Hi,
Richard might not like to hear this but I think the G-P-M development
is on the wrong track. It started with the aim to build a GUI for power
management features. So far so good. But in the meantime it piles more
and more power management functions and because it runs with user
privileges and need someone to do the dirty work, clutters HAL with low
level power management functions which it is not designed for.

Continuing this path will cause a dilemma for the end user: He has to
decide between a well working power management (for example on powerpc
machines, see pbbuttons.sourceforge.net) and the gnome desktop, because
G-P-M has the GUI he or she likes but the functionallity breaks all
other power management concepts (daemons).

I would like to suggest a slightly change of project aims:

1. HAL
The HAL specifications tells that HAL provides a view and detailed
metadata to attached hardware, not more. Not a word about building the
mega-system-do-everything daemon.

Please return to this aim. Limit HAL's functionallity to collect data
from various sources and provide it to the desktop for visualisation.
According to the specification it is not HAL's task to actively control
certain hardware or start scripts because of desktop programs wanted so.

2. G-P-M (Desktop Part)
The G-P-M project description on gnomefiles.org sais: "The main focus
here is the user interface; e.g. allowing configuration of power
management from the desktop in a sane way"

This is exactly what G-P-M on the Desktop should do. Visualize data
provided by HAL and comunicate with a power management daemon through
dbus, but don't perform any power management functions by itself.

3. The Power Management Daemon
Power management is too critical to lay it in user's hands. It is an
important system feature and must be handled by a system daemon running
with high privileges. No desktop program is able to fulfil this task.

Divide G-P-M in two parts (projects):
 part 1: Desktop module which visualize interesting data to the user
         including configuration dialogs
 part 2: a power management daemon that do the dirty work, provide data
         to HAL and receive orders from desktop programs through dbus.

This concept has a lot of advantages:
 - It won't break with existing power management structures. Migration
   is possible in small steps,
 - The user can use the Desktop tools with a power manager he likes,
 - the new power management daemon will cooperate with all desktops,
   not only with Gnome,
 - HAL can fulfill its job straight forward. No foreign code anymore.


There are sill a lot of questions to answer but I think this concept is
future proof and bring power management on Linux a step forward. There
are a lot of good ideas in G-P-M and a lot of highly motivated and
entusiastic people push it forward with breathtaking speed but it seems
to me that the big plan is incomplete or missing at all. Also everything
is eyed through the Gnome spectacles only but power management is not a
Gnome only issue.

I have developed pbbuttons (power management daemon for Linus on Apple
computers) for four years now and I would be pleased to join the team
developing the new power management daemon I described above.

I'm awaiting your feedback.

 Best Regards
   Matthias

Re: Hello! Problem with non existing device /dev/adb

[Matthias G. <mat...@us...>]

On Fri, 07 Oct 2005 20:05:05 +0200
Mirko Vogt <mir...@we...> wrote:

> Hi!
> 
> I'm using slackintosh-current (~10.2 I think ;)) and installed the 
> pbbuttons-daemon.
> But it didn't start, becuase there is no device called adb in /dev/.
> is it safe to create it with mknod? If yes, what are the parameters?

Yes, it is safe to create it with mknod

  mknod -m 660 /dev/adb c 56 0

should do it. Owner should be root.

 Best Regards
   Matthias

Hello! Problem with non existing device /dev/adb

[Mirko V. <mir...@we...>]

Hi!

I'm using slackintosh-current (~10.2 I think ;)) and installed the 
pbbuttons-daemon.
But it didn't start, becuase there is no device called adb in /dev/.
is it safe to create it with mknod? If yes, what are the parameters?
If not, what's the way to get this device?
I have an iBook G4 1,2 ghz.

Thanks a lot!

Mirko Vogt

PBButtonsd Version 0.7.2 released - minor feature extension and bugfix

[Matthias G. <mat...@us...>]

Hi,

a new pbbuttonsd version is out.

PBButtonsd now cooperates with the appletouch trackpad driver as well
as with most graphic tablets. Furthermore a new HIBERNATE command was
added to improve support for suspend-to-disk and last but not least
pbbuttonsd won't suspend the machine anymore if a shutdown or reboot
process is already in progress.

This release was checked with valgrind for the first time and as result
some memory leaks and other minor problemes were fixed, too. Read the
changelog for full list. 

Download is available as usual on http://pbbuttons.sourceforge.net

 Matthias

Re: Question about CFLAGS handling in configure.in

[Matthias G. <mat...@us...>]

On Fri, 30 Sep 2005 00:57:59 +0200
Frank Lichtenheld <dj...@de...> wrote:

> If you want to really simplify things just delete the whole code block
> and let users always decide which CFLAGS they want by specifying them
> to ./configure.

Ok, I like thinks simple :-) I will remove the code in the next releases.
I tested it with pbbuttonsd so far and it worked good.

> (I used that ocasion of fiddling with Makefile.am to also update the
> gtkpbbuttons automake stuff to automake 1.9)

What have you changed here?

I don't like automake 1.7 and higer much because you get a lot more
warnings which I don't know what they are talking about. Furthermore
you can't easily see anymore which file is currently compiled becasue
each compiler call is embraced with a shell script and the output
clutters the terminal window. Why can't they filter the output like the
kernel Makefile does? Nevertheless you should be able to use automake
1.9.

 Best Regards
  Matthias

Re: mac-mini power button

[Matthias G. <mat...@us...>]

On Thu, 15 Sep 2005 10:01:43 +0200
pix <pi...@te...> wrote:

> hi,
> 
> i was trying to get pbbuttons to detect the mac-mini power button. by
> running: 
> 
> od -t x1 -w1 /dev/pmu
> 
> i could see that on pressing the power button, the bytes [0x40 0x0c] are
> generated. when you release the button, [0x40 0x04] is generated.

I checked the pmu polling routine of pbbuttonsd again and saw that your
power button should already work if the pmu message is 6 bytes long. How
much bytes will be send by the pmu? Only two you wrote in the mail or
more?

In case it sends 6 Bytes pbbuttonsd generates the fake keycode 116 for
the power key. This keycode can then be used inside pbbuttonsd. Set
Sleepkey = 116 and it should work.

If your PMU only sends two bytes, I have to patch pbbuttonsd.

Please send me the contents of /proc/pmu/*.

  Best Regards
   Matthias



 
> i tried adding this to the module_pmac.c file, but then i noticed a
> bigger problem. it appears that when running on the mac mini, pbbuttonsd
> doesn't even listen to /dev/pmu. to check, i turned on PMUINTR in
> debug.h and compiled with -DDEBUG. i get a lot more debug info, but i
> don't get the expected line printing out the bytes that i know are being
> generated at /dev/pmu... so i assume somewhere during startup, pbbutons
> makes some decision not to monitor /dev/pmu.. possibly because it
> doesn't support many laptop-like functions, such as sleeping (this is
> also why pmud doesn't want to start on the mac-mini).
> 
> anyhow, i have resorted to writing a small program which does nothing
> but monitor /dev/pmu, and hand off any read bytes to a script, which
> then halts the machine is the power button is pressed.
> 
> it is available here... http://f0.am/darcs/lyta/system/pmumon/ the
> install rule is very debian-centric, sorry. also, the rcd script
> included sets server_mode in /proc/pmu/options, which is something very
> peculiar to our setup here, and possibly isn't what you want.
> 
> it would probably be better for this *cough* feature to be incorporated
> into pbbuttonsd, but it seems a few people are trying to get their
> mac-mini power buttons to work like this, so i've made this available.
> 
> i hope this is useful for the developers, unless there is some policy
> about not supporting desktop machines...
> 
> pix.
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. 
> Download it for free - -and be entered to win a 42" plasma tv or your very
> own Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> pbbuttons-users mailing list
> pbb...@li...
> https://lists.sourceforge.net/lists/listinfo/pbbuttons-users
> 

Re: [patch] pbbuttonsd should not go to sleep on init 0 ?

[Matthias G. <mat...@us...>]

On Wed, 28 Sep 2005 13:28:59 -0400
Kristian Benoit <kb...@op...> wrote:

> > The problem with this, is that init send a term to it's childs, wait 1-5
> > seconds then send a kill. In 5 seconds, you have the time to close the
> > lid.
> >  
> > > Maybe I'm saying something stupid but, could pbbuttonsd simply always
> > > check current runlevel before making the *book go to sleep?
> > >
> > > If current init is 0 (or 6? maybe not a good idea?) it just doesn't go
> > > to sleep.
> > 
> > Yeah!! seems like the best idea !! here's the patch :)

I checked you patch and found no better solution to evaluate if a
shutdown is in progress. Because with all other mentioned solutions a
small chance to fail is remaining (killing pbbuttonsd very early during
shutdown might be not early enough). Due to this I accepted the patch.
The next version won't suspend the machine anymore if a shutdown or
reboot process is in progress.

Because the method with utmp is very system specific (only on Linux a
utmp file always exists), this code might not be useable on other
systems than Linux. If the utmp file did not exist, pbbuttonsd would
suspend the machine as usual.

If anybody has a system independent solution to get the current
runlevel I would appreciate any help.

 Best Regards
   Matthias