Re: [gpm] Limiting inhibition by applications

["Odysseus Flappington" <deriziotis gmail com>]

2009/1/1 Milan Bouchet-Valat <nalimilan club fr>:
> Hi again!
>
> I'm wondering how you feel about the issue I raised about a month ago. I
> received one positive answer, but how do you think this should be fixed?
> By a mere return to the previous behavior, or by introducing new calls?
> Richard Hughes, any ideas?
>
>
> Cheers
>
>> On Nov 29, 2008, Victor Lowther wrote:
>> On Fri, 2008-11-28 at 23:39 +0100, Milan Bouchet-Valat wrote:
>>
>> > Hi!
>> >
>> > In recent GNOME versions, more and more applications use D-Bus to
>> > inhibit suspend and hibernate when they're working on tasks that
>> should
>> > not be interrupted. This is great and I love how this communication
>> > system works.
>> >
>> > However, at least since 2.24, manual suspend (as opposed to
>> > automatically trigger by inactivity) is forbidden when an
>> application
>> > has told g-p-m to inhibit this action. This results in a nice
>> > notification explaining (very well designed) who and why.
>> >
>> > IMHO this is a little too much: for example, I'm using Transmission
>> in
>> > the background, and it logically prevents the system from
>> suspending
>> > automatically, so that downloading is not stopped. But sometimes I
>> want
>> > to hibernate, and restart my computer later, and I'd like my
>> downloads
>> > to resume then. But g-p-m forbids me to do so, and I'm forced to
>> stop
>> > manually Transmission before hibernating, thus I need to restart it
>> > later, and it reduces the interest of hibernate/suspend.
>>
>> Transmission even inhibits the screen from blanking or entering any
>> VESA
>> powersaving modes -- I guess displaying bittorrent status updates is
>> just that important. :/
>>
>> > What I think is that inhibition should not prevent users from doing
>> > anything. This is absolutely frustrating; instead, the desktop is
>> here
>> > to work for me. So would there be an issue if we force hibernation
>> has
>> > it was before? I can imagine it may be complex: Rhythmbox doesn't
>> care
>> > if I hibernate while playing, but Brasero would trash my CD-R. And
>> > Transmission would like to be made aware of hibernation so that it
>> can
>> > close connexions with the server before that.
>> >
>> > Would an extension of the current design make sense? I'm thinking
>> of
>> > news functions that the apps could use according to their needs,
>> like:
>> > absolutely inhibit suspend/hibernate; please just tell me before
>> the
>> > system hibernate, and trigger a callback function; merely inhibit
>> > automatic sleep. This would be more flexible and more suited to what
>> a
>> > desktop really needs. What do you think? I can have a look at the
>> code
>> > if it's worth... Or maybe this should go in DeviceKit-Power?
>>
>> IMHO, gnome-power-manager should never inhibit a manually-initiated
>> state transition of any kind.  When I close the lid of my laptop and
>> chuck it into my backpack, I expect it to suspend, and if an app does
>> not like that it can sod off -- doesn't matter what it is doing or
>> how
>> important it thinks that task is.
>>
>> > Cheers
>> >
>> > _______________________________________________
>> > gnome-power-manager-list mailing list
>> > gnome-power-manager-list    
>> > http://mail.gnome.org/mailman/listinfo/gnome-power-manager-list
>> --
>> Victor Lowther
>> RHCE# 805008539634727
>> LPIC-2# LPI000140019
>>
>> _______________________________________________
>> gnome-power-manager-list mailing list
>> gnome-power-manager-list    
>> http://mail.gnome.org/mailman/listinfo/gnome-power-manager-list
>
>
>
> _______________________________________________
> gnome-power-manager-list mailing list
> gnome-power-manager-list gnome org
> http://mail.gnome.org/mailman/listinfo/gnome-power-manager-list
>

You're absolutely right, manual suspend should never be inhibited (I
don't see any situation or any type of inhibit that should be able to
be called to stop a manual suspend ever). I'm on Hardy on my laptop
which is Gnome 2.22, so I can't confirm that 2.24 breaks this
behaviour.

If it does though, someone should write a patch and submit it to the
devs. I have never been able to find the devs of GPM tho, and I've
never seen patches applied on this list, so I'm not sure who to
contact to get this fixed.

Anyone else know where to go?

Alex