Hi Thomas, 
just to help identify the area more quickly, can you point us to where the timer setting are? For example in TDEPowersave I can see a 120min limit in my system.

I can confirm this.. I have also maximum of 120 minutes in tdepowersave (TDE 14.0.3, Wheezy) but I guess bug is more like against all artificial limits like 99/120/whatever minutes..

err sorry for typo 14.0.2

Created attachment 2633 [details]
Screenshot showing the arbitrarily limited setting for autosuspend

I'm very surprised to hear, that others have a limit of 120 minutes.
That makes me wonder, were it comes from -- in the source I found nothing ...

Nevertheless, such a limit should not exist, or be at least at 999 minutes (16+ hours), to adapt sufficiently to user needs, IMHO.

I have increased the maximum time for several timer to 1500 minutes (25 hours). This should be enough to satisfy most people :-)
Push to main trunk in commit b31060a and R14.0.x in commit 56865f6.

Regarding the description of the different suspend modes, I think it would be a good idea to uniform the writing to the ones used in the logout menu. For example "Suspend to RAM" -> "Suspend computer". 
What do you think?

(In reply to Michele Calgaro from comment #5)
> I have increased the maximum time for several timer to 1500 minutes (25
> hours). This should be enough to satisfy most people :-)

Yes, most ;-)

But, honestly, why a limit at all?

I'd leave it completely to the user's discretion (the UNIX way), because I surely know that I can't anticipate all smart uses for a feature, intelligent users can come up with. And I surely know, how frustrated I am, if some good idea is foiled by an arbitrary limitation ...

> Push to main trunk in commit b31060a and R14.0.x in commit 56865f6.

Interesting to see, that that is purely UI description based -- so there is no technical reason at all. If the UI description really requires some upper limit it should at least provide for a "long weekend", or 9999 minutes ...

> Regarding the description of the different suspend modes, I think it would
> be a good idea to uniform the writing to the ones used in the logout menu.

Uniformity of terms within TDE would definitely a good thing!
(despite the potential trinity of TDE, ACPI, and kernel terms, even uniformity at least with kernel terms would help the user browsing the Web for solutions ;-)

Alas, the name space has been muddled over the years:
freeze/thaw, sleep, hibernate, suspend, ...

> For example "Suspend to RAM" -> "Suspend computer". 
> What do you think?

Actually I'd prefer the more concise and descriptive "Suspend to RAM", maybe even "Suspend to RAM (ACPI G1/S3 mode)". ("Suspend computer" might raises to many questions for the typical DAU: by it's power cable? from the balcony? on the clothes line? but why? ]8-} )

That approach would leave us with the like of:
1. "Freeze or 'Power on Suspend' (ACPI G1/S3 mode)"
2. "Standby ?????" (ACPU G0/S0 "awaymode" or G1/S2 ???) <-- to be clarified!
3. "Suspend to RAM (ACPI G1/S3 mode)"
4. "Suspend to RAM+Disk (hybrid of ACPI G1/S3+S4 mode)"
5. "Suspend to Disk (ACPI G1/S4 mode)"

> Interesting to see, that that is purely UI description based -- so there is no 
> technical reason at all.
There are two reasons I kept a limit on it:
1) to prevent situations where the user can add a timer so big that this would exceed the actual capability of the timer object used to do the countdown. I am not even sure this could happen to be honest, but prevention is better than curing said a famous italian advertisement many years ago
2) a user could mistakenly type a wrong value (for example hitting an additional key) without realizing it. Forcing a limit would require user intervation in case of very big values.

Of course the limits can be removed, it is just a few lines of ui xml code.

> Actually I'd prefer the more concise and descriptive "Suspend to RAM"
That is also an option, perhaps more clear than the existing one aws you said. In that case we should change the writing in the logoff menu and not in TDEPowersave.
I suggest a compromise as this:
1. Power on Suspend
2. Standby (?????)
3. Suspend to RAM
4. Suspend to RAM+Disk
5. Suspend to Disk
without the technical state names, which ordinary users may not like.

Slavek, please also share your view with us :-)

(In reply to Michele Calgaro from comment #7)
> There are two reasons I kept a limit on it:
> 1) to prevent situations where the user can add a timer so big that this
> would exceed the actual capability of the timer object used to do the
> countdown. I am not even sure this could happen to be honest, but prevention
> is better than curing said a famous italian advertisement many years ago

But not knowing the actual timer limit makes the current limit "unsafe" too,
so this needs clarification anyhow ...

> 2) a user could mistakenly type a wrong value (for example hitting an
> additional key) without realizing it. Forcing a limit would require user
> intervation in case of very big values.

Personally I'm a hard-and-die UNIXoid, so absolutely not in favor of user nannying. In the specific case no real harm will come from an user mistyping: the machine will not auto-suspend at the expected time, which might be shorter or longer as intended (you mayhaps only catch the "longer"). This in the worst cause some electricity wasted and some unnecessary wear on HW, but it might teach the users to actually verify what they were configuring (which is a good thing).

If I on the other hand need a longer period (e.g. for a ray-tracing or circuitry layout job run 4-5 days over a long weekend, but want to take precautions, if I should become sick ...), what kind of "intervention" is the (normal) user expected to do?

I would hack the config file via "vi", but that is not what I'd consider normal user intervention. Further I can't be sure, that TDE is honoring my manual edit and circumvention of the limit: "TDErandrtray" for example in it pseudo-wisdom decides it knows better than me, and simply enforces its rules nevertheless ...

> Of course the limits can be removed, it is just a few lines of ui xml code.

Kindly do so, or at least raise to 10 days ...
(if really needs be, an infamous "are sure?" box could be added for >24h)

> > Actually I'd prefer the more concise and descriptive "Suspend to RAM"
> That is also an option, perhaps more clear than the existing one aws you
> said. In that case we should change the writing in the logoff menu and not
> in TDEPowersave.
> I suggest a compromise as this:
> 1. Power on Suspend
> 2. Standby (?????)
> 3. Suspend to RAM
> 4. Suspend to RAM+Disk
> 5. Suspend to Disk
> without the technical state names, which ordinary users may not like.
> 
> Slavek, please also share your view with us :-)

The technical details were meant for documentation and/or the help-bubbles ...

Hi Thomas,
I wanted to remove the limits as per your request, but I have found out the reason why there must be a limit. It is very simple. If the maxValue property is not specified for the TQSpinBox object, the maxValue is by default set to 99.
So I have set the max value to 50000, which is about 34.7 days.
If you are happy with that, we can close this bug.

Commit 2f0cf52 (master) and 504511d (r14.0.x)

Forgot to mention. Regarding the command naming in the logout menu, there is already bug 2602, so we can continue the discussion there.
This bug is therefore only about the time limit.

(In reply to Michele Calgaro from comment #9)
> Hi Thomas,
> I wanted to remove the limits as per your request, but I have found out the
> reason why there must be a limit. It is very simple. If the maxValue
> property is not specified for the TQSpinBox object, the maxValue is by
> default set to 99.

Then, very obviously we have to make up a limit from thin air.

> So I have set the max value to 50000, which is about 34.7 days.
> If you are happy with that, we can close this bug.

Yes, I'm completely happy with that: it should cover beyond 99.999999% of imaginably use cases and that is sufficient to claim the existence of the Higgs particle, gravity waves, and the closedness of this bug ;-)