On Fri, 2009-11-13 at 15:03 +, Matthew Garrett wrote:
> Bear in mind that with current kernels, resume should work without
> quirks on all intel and radeon, and will basically never do anything
> useful on nvidia. These are very much a legacy holdover, and at this
> point I'd recommend dropp
On Mon, 2007-06-04 at 19:30 +0200, Holger Macht wrote:
> So in future versions, as soon as the TODO item is done, wouldn't
> it make sense to remove the hook from pm-utils and let hald-addon-cpufreq
> care about proper suspend/resume handling to have everything in one place?
I suppose so. But as w
On Wed, 2007-03-14 at 11:39 -0400, David Zeuthen wrote:
> I'll look into into integrating the pm-is-supported + hybrid suspend
> into HAL today. Then HAL master will depend on that version of pm-utils
> or newer. Thanks.
This is now committed
http://gitweb.freedesktop.org/?p=hal.
On Wed, 2007-03-14 at 12:05 -0400, Peter Jones wrote:
> On Wed, 2007-03-14 at 13:56 +0100, Olivier Blin wrote:
> > David Zeuthen <[EMAIL PROTECTED]> writes:
> > > It tells HAL to rescan the battery - in case someone changed the battery
> > > we want the new serial
On Wed, 2007-03-14 at 11:00 -0400, Peter Jones wrote:
> On Tue, 2007-03-13 at 14:45 -0400, David Zeuthen wrote:
>
> > It tells HAL to rescan the battery - in case someone changed the battery
> > we want the new serial number etc... if I recall Peter's reasoning
> >
On Tue, 2007-03-13 at 19:35 +0100, Stefan Seyfried wrote:
> dbus-send --print-reply --system --reply-timeout=2000 \
> --dest=org.freedesktop.Hal $x \
> org.freedesktop.Hal.Device.Rescan string:$x
[...]
> so what does this monster do? Why i
On Tue, 2007-03-13 at 19:38 +0100, Holger Macht wrote:
> Huh? This is already done in hal-system-power-hibernate-linux after
> pm-utils was called to suspend? Why is this needed again?
You're right. So this should be removed from pm-utils and I don't need
to add anything to HAL :-)
David
_
On Tue, 2007-03-13 at 06:54 +0300, Andrey Borzenkov wrote:
> On Monday 12 March 2007, David Zeuthen wrote:
> >
> > - a new property on HAL called
> >
> > power_management.can_suspend_hybrid
> >
> >to go with .can_suspend and .can_hibernate
&
On Mon, 2007-03-12 at 17:37 -0400, Peter Jones wrote:
> On Mon, 2007-03-12 at 15:52 -0400, David Zeuthen wrote:
>
> > Peter, is this something you can look at / comment on?
>
> Well, for this to work, we need the kernel to write out the data to the
> swap file without pow
On Mon, 2007-03-12 at 22:46 +0100, Danny Kukawka wrote:
> On Montag, 12. März 2007, David Zeuthen wrote:
> > On Mon, 2007-03-12 at 21:42 +0100, Danny Kukawka wrote:
> [...]
> > > Do they? KPowersave for example depend on *.c
On Mon, 2007-03-12 at 21:42 +0100, Danny Kukawka wrote:
> On Montag, 12. März 2007, David Zeuthen wrote:
> > I know perfectly fine what HAL reports. The thing is, applications today
> > rely on the .can_hibernate method to actually do something useful like
> > presenting the u
On Mon, 2007-03-12 at 21:22 +0100, Holger Macht wrote:
> > This is really just a third sleep mechanism so what I think we need is
> >
> > - a new method on HAL called SuspendHybrid() - this is on the same
> >interface as Suspend() and Hibernate()
> >
> > - a new property on HAL called
> >
Hi,
Please don't cut Cc's.
On Mon, 2007-03-12 at 21:02 +0100, Danny Kukawka wrote:
> On Montag, 12. März 2007, David Zeuthen wrote:
> > Now, there's a bug in HAL already in how we compute the .can_suspend
> > and .can_hibernate values. For example, here on Fedor
On Mon, 2007-03-12 at 08:52 +0100, Stefan Seyfried wrote:
> Do not even think about s2both in upstream pm-utils, since there is apparently
> no interest in including userspace-suspend support (at least my patches get
> silently dropped all the time) at all.
Why is that? Who is not interested in do
On Sun, 2007-03-11 at 01:13 +0100, Tim Dijkstra wrote:
> Hi,
>
> Both suspend.sf.net and suspend2 have a notion of s2both. That is,
> before suspending to ram, the state of the system is saved to disk just
> like would happen for hibernate.
> This has the obvious benefit of being able to resume in
Hey,
I'm planning to release hal 0.5.9 very soon (just put out RC1 so
hopefully this week barring getting some bugs fixed) so is it possible
we can get a release of pm-utils? Thanks!
David
___
Pm-utils mailing list
Pm-utils@lists.freedesktop.org
On Tue, 2007-02-20 at 21:01 +, Richard Hughes wrote:
> On Tue, 2007-02-20 at 21:30 +0100, Stefan Seyfried wrote:
> > Before getting towards 1.0, shouldn't we move over from /etc/ to
> > /usr/lib/pm-utils or something like that to be FHS compliant? Somebody
> > mentioned recently to me that havi
On Tue, 2007-02-20 at 20:27 +, Richard Hughes wrote:
> On Tue, 2007-02-20 at 15:19 -0500, Peter Jones wrote:
> >
> > David and I were talking about the quirk- thing on irc, and decided to
> > leave it in. It doesn't hurt anything, and it makes them sort into
> > one
> > block in e.g. the "--h
On Tue, 2007-02-20 at 20:10 +0100, Stefan Seyfried wrote:
> Next thing i noticed is 65alsa.
> This is clearly working around a broken sound driver, isn't it?
> How about fixing the driver instead?
Strong agreement. I'd hate to see this on by default in the pm-utils
tarball and, FWIW, I'd also hate
On Wed, 2007-02-07 at 20:13 +0100, Stefan Seyfried wrote:
> Weren't there plans to let HAL pass these hacks down in environment
> variables or commandline options to pm-suspend? This would be much easier
> IMO.
I think that was the plan. I don't feel good about making pm-utils
depend hal; we reall
On Tue, 2007-01-09 at 00:18 -0500, Peter Jones wrote:
> I want to make it actually work to hibernate 2.6.19 first ;) It's
> probably an hour or two of work, but it needs to be done. I really
> meant to do it Friday, but, well, I was delirious with fever and could
> barely sit up or focus my eyes.
On Mon, 2007-01-08 at 10:29 +, Richard Hughes wrote:
> Brilliant, thanks. I'll get someone to throw a stapler at pjones[1] and
> see if we can get a formal pm-utils release out.
I actually tried this several times (Peter's cube is one and a half cube
away from mine) but with no effect resultin
Hi,
On Tue, 2007-01-02 at 21:31 +, Richard Hughes wrote:
> Referring to http://bugzilla.gnome.org/show_bug.cgi?id=392022
>
> powermode=`/usr/bin/aticonfig --lsp | grep -m1 low | cut -b 3-3`
> /usr/bin/aticonfig --set-powerstate=$powermode --effective=now
>
> sets the power consumption to lo
On Tue, 2006-11-28 at 00:01 +, Richard Hughes wrote:
> Okay, can you have a look at the sample file attached, and tell me what
> you guys think.
>
> I'm in two mind about the 'contains=' match - I know computationally
> strstr is bigger compared to strcmp, but I'm trying to do as much binary
>
On Mon, 2006-11-27 at 18:27 +, Richard Hughes wrote:
> On Mon, 2006-11-27 at 13:03 -0500, David Zeuthen wrote:
> > One nitpick however... I'd like to see the properties prefixed with
> > power_management.quirk.* instead of video_adapter_pm.* - is that
> > alright?
On Sun, 2006-11-26 at 23:14 +, Richard Hughes wrote:
> (first, sorry for the cross posting, but I think I need to...)
>
> I guess we still want video adapter blacklisting in HAL for identifying
> stuff like vbe restore and s3mode. I think we came to the consensus that
> we should specify argum
Holger Macht wrote:
The stuff in HAL will still write a preamble (with e.g. /sbin/lsmod output) and possibly a postamble too. I think
that belongs in HAL, not pm-utils, because HAL provides the asynchronous error handling, pm-utils does not.
But if it would be done in pm-utils, pm-utils would a
Holger Macht wrote:
HAL can just copy it over to its own namespace, then it's owned by HAL.
Hmm, I guess we're arguing details right now which means we basically agree
:-)
Yes, I think so. I'm not arguing about the general idea about the error
handling. I just would like to see pm-utils
Holger Macht wrote:
I think pm-utils should be the only one writing a logfile about a thing it
knows about and actually executes.
Disagree; the logfile is to be owned by HAL since HAL provides the
ABI/API to access / delete it. It's really just delayed error handling
using a well-define mecha
Holger Macht wrote:
Additionally, can we let pm-utils return one descriptive message about the
reason for the failure, if one is present? Nothing very verbose, just
something like 'Module xz failed to unload' (just an example, of
course). This would be something that can be shown to expirenced us
Holger Macht wrote:
Why can't we use /var/log/pm-{suspend,hibernate}.log created by pm-utils
instead? We are currently working on pm-utils being more verbose.
I just see that your patch is actually doing this, redirecting the output
of pm-utils (which is the same as the content of the logfile)
On Thu, 2006-11-09 at 21:11 +, Richard Hughes wrote:
> Yes, it needs some cleanup but I can do this for you on HEAD.
Yea, it was a quick one hour job, was working against the clock, sorry.
> Are you
> definitely committing that code into HAL CVS or are we going to argue
> about things some m
Hi,
Sorry for being slow in responding.
Attached are the patches I put in the RHEL beta, been tested somewhat
thoroughly and appears to work fine insorfar that the user gets a dialog
if suspend fails.
diffstat hal-0.5.8.1-powermgmt-output-4.patch
fdi/policy/10osvendor/10-power-mgmt-policy.f
On Fri, 2006-11-03 at 19:20 +, Richard Hughes wrote:
> When the stuff hits HAL CVS, I'll add support into g-p-m.
Cool, sounds good. I think we (Red Hat) might want to backport it into
the g-p-m 2.16 we're shipping in RHEL5 but that's probably not going to
be too hard. Thanks.
David
___
On Fri, 2006-11-03 at 17:21 +, Richard Hughes wrote:
> > - For Suspend() let HAL capture the output of the tool being invoked
> >to a file /var/lib/hal/suspend-output
>
> you mean have pm-suspend quit with exit code 3 and report "Device failed
> to sync" as an example?
Yea. That would ju
On Fri, 2006-11-03 at 12:00 -0500, Bill Nottingham wrote:
> David Zeuthen ([EMAIL PROTECTED]) said:
> > I'm adding the pm-utils list as Cc as I want to make sure we can get
> > useful logging output. I think HAL would just use an option
> > --log-verbose-output-to-stder
Hi,
For your consideration here's a proposal to make the desktop bits better
deal with Suspend/Resume failures. It's the output of some discussions
with mclasen, rstrode, jrb and myself over the last few days.
Traditionally what happens today is that invoking Suspend() on the
o.fd.Hal.Device.Sys
On Wed, 2006-05-24 at 18:46 +0100, Richard Hughes wrote:
> On Sun, 2006-05-21 at 23:39 +0100, Richard Hughes wrote:
> > How about we convert pm-utils to use automake and configure (like most
> > other OSS projects) so we get stuff like "make dist-check" for free.
>
> As requested, patch attached.
Hi,
(adding hal list to the Cc)
On Sun, 2006-05-21 at 23:39 +0100, Richard Hughes wrote:
> "make create-archive" still doesn't work for me - it pulls an old CVS
> version.
>
> How about we convert pm-utils to use automake and configure (like most
> other OSS projects) so we get stuff like "make
On Mon, 2006-05-01 at 19:17 +0100, Matthew Garrett wrote:
> (I think several of the powersave "powersave" and "performance"
> distinctions are bogus - we can do better than that by figuring out
> what's actually needed rather than just having static configurations
> that mostly just serve to giv
On Mon, 2006-05-01 at 23:30 +0200, Holger Macht wrote:
> > > Do you mean an Uninteruptible Power Supply aka, an UPS? Yes, HAL and
> >
> > no, something like:
> > http://www.sps-ltd.com/product/external/max90/max90.htm
>
> Thanks, Stefan! I'm looking for such a link already for about 20 Minutes
>
On Mon, 2006-05-01 at 20:53 +0200, Holger Macht wrote:
> But there are situations where you definitely need to change the policy
> manually. Imagine an external power supply. I don't know what the english
> term is, it's just a big battery which you can plug into the usual ac
> interface. It's no b
42 matches
Mail list logo
