Hi,

maybe I'm missing something. But on my Thinkpad x100e hibernate and suspend work very well. I use acpi-events.

First step is using the acpi_listen command as root. This command shows which code is associated with an acpi-event. For example closing the lid, power-button and so on. You should check the acpi-events for any function key.

Then you go to /etc/acpi and chmod 644 the acpi_handler.sh in order to prevent the system from rebooting when the powerbutton is pressed.
Then you put some scripts in your /etc/acpi/events. For example on my Samsung there is a /etc/acpi/events/hibernate script with the following content:After restarting the acpi-daemon it should work.

As of the acpi-events, this scripts allways run as root and are therefore independet of the user who closes the lid or presses the power-button.

I'd recommend to read the manpage for acpid.

Markus

They work on my T400 too. My point of "confusion" is they don't work out of the box, which is silly. Look at your own post and the extra effort required. :)

Statements like that confirm that none of this works out of the box. :)

Well, out isn't possible for acpi-events because the code is different for any laptop.

Well, I meant to look at man acpid instead of man acpi (which doesn't exist).

In fact I use the "sleeping" functional key (the blue moon ;) ) on my Thinkpad for suspend and the powerbutton for hibernate and it works very well.

Markus

Yet Windows does that automatically for all laptops?

That wasn't the point I wanted to make (I hadn't even noticed that.). :) My point was that users need to consult man pages to get basic features working.

I use Fn-F4 as well closing the lid, but neither of those options, which required me to surf the web to learn about and manually configure, enables applets to perform energy saving. I purchased the T400 used with XP preinstalled and all of the energy features "just work" as well as the special function keys. I don't use XP and have been using Slackware for many years, but hard not to notice things like that. :(

As you know any hardware is primary made to be compatible with Windows...
Yes, that's the difference between Windows and any good operating system :)Well, there's one thing which will help you soon. Just use Windows (or Ubuntu) for a while, you'll be back to Slackware very soon and happier than before.... ;)

Markus

You're just being difficult now. I have no intention of using Windows full time and never implied as much. I never implied I'm unhappy with Slackware. I have no idea how you determined that.

I raised an issue that exposed something that is not user-friendly. Not even close to being user-friendly. That is the limit of the discussion. :)

I've never understood why some free software users defend aspects of the software that are not user-friendly. The goal should be to make things easier to use and not to defend archaic propeller-head practices. :)

Well, then let us take this thread as a starting point and consider how we can contribute and solve this issue. Maybe we could write a script which helps the user to configure acpi-events (similar to netconfig). I don't know if it is possible to detect the correct settings for acpi automatically. But I know there is a script from Robby Workmann which helps to test if a laptop can suspend and hibernate.
I'll think about a solution. Anyone an idea?

Markus

Although I am an experienced Linux/Slackware user, this laptop is the first I have owned, which means I'm very much a newbie with respect to laptops. Like many topics, I think long-time laptop users overlook the differences between desktop and laptop systems. My experience with computers, Linux, and Slackware, and inexperience with laptops provides me a unique perspective,

From my user experience, sleep and hibernate must be readily available to non root users. This is just not the case on Linux systems. I browsed many how-tos and I was suprised that something as basic sleep/hibernate is not available to non-root users without a lot of tinkering. Scripts should be pre-installed. Special function keys should "just work."

I fiddled with the preinstalled Windows XP for only a day because I had no experience with a laptop. I needed a reference point. I wanted to see and understand how these features function on a laptop, at least on Windows. Having only used desktop systems, I never really had a use for sleep or hibernate.

Even grabbing battery information is not straightforward with Linux based systems. I had to search the web to find the answer and even then, the solution is command line. Non technical users, and users coming from Windows, expect more, and need more.

I'm sure some applets exist that manage this kind of thing. I don't use Xfce or KDE. I use Trinity. After I searched the web to discover how to configure Fn-F4 and the lid, I then proceeded to configure some of the Trinity applets for power management. They didn't work because the default permissions for /sys/power/state are root only and no appropriate script yet existed in /etc/polkit-1/localauthority/50-local.d. In fact, the parent directory is chmod 600, which to me is silly. No, not silly but stupid.

All of this is much the same as Torvalds' rant about configuring printers. I understand security, but a laptop needs sleep and hibernate functions to just work --- for non-root users.

I don't know what solutions are possible but until permissions and scripts are installed and configured automatically, then the entire support system for non-root users will remain broken. :)

That's the spirit!

And in this spirit, I offer some thoughts. First, it makes sense to get a little organized. The varied responses in this thread show people use various mechanisms to enter S3 or S4 states and may be unaware of the different characteristics of each method or even that they differ.

As far as backends we have:

1. swsusp: which can be invoked directly with things like: echo {mem,disk,both} > /sys/power/state
2. uswsusp: which in the case of s3 is a wrapper to swsusp and in the case of s4 is a complete userland implementation.
3. tuxonice: set of kernel patches that provide a versatile and feature-rich extensible kernel-land framework.

As for higher-level mechanisms, we have:

1. pm-utils: wrappers to upower; used to wrap HAL
2. acpi events: event-triggered suspend/hibernate (buttons, lids, etc.)
3. polkit with upower actions: used by polkit-aware applications
4. others

Each system has its reason for being. Often higher-level methods allow for "hardware quirks" (both on power-down and thaw) as well as other abstractions.

Why quirks? Unfortunately, not all HW reacts well to being placed in low-power mode for later thawing. Sometimes it's a design limitation/flaw and other times it is closed specs not made available to Linux hackers thereby generating obstacles to driver development.

As for Slackware defaults, the OP mentions one use-case: the single-user laptop. We should keep in mind Linux is a multi-user system by design and laptop single-users don't represent 100% of the user base. We should not suggest Slackware defaults that trigger other threads like "Why is user Joe Q. Public able to shut down my server?". Alternatively, one can envision a Slackware installer which sets defaults based on user input (server, single-user desktop, single-user laptop, etc.). Sounds like a good deal of work to me so it will probably require strongly lobbying those who would do the actual work. It also raises a philosophical issue of how much Slackware wants to move towards becoming a more hands-off type distrib. I suspect not much.

Some S3/S4 frameworks such as using upower via polkit can be adapted easily to allow a subset of privileged users (say members of the power group) to suspend/hibernate as I showed in post #4. Later posts made me doubt whether Slackware affords the power group upower suspend authority by default without the need for a local authority. I am unable to test a clean install now but that should be easy enough to determine.

Other higher level mechanisms, as mentioned, will be more difficult to fully automate as HW configurations vary wildly across users. A more realistic goal is for automation, if desired, to cover only the more common configurations.

--mancha

All I'm seeing it just too much information on a very simple procedure. Ultimately the action that ends up being performed is an 'echo mem > /sys/power/state'. If I see another way to do the same thing, I'd think my brain will explode.

Now I totally agree that the lid close event is very hardware dependent, but also should just work out of the box. I don't know why my eeepc can simply do it out of the box now. It seems someone using the hardware automatically configured the event to be sent to an event handler, and checks permissions and send dbus messages, and soon it's on it's way to another script that does the pm-suspend routine which finally calls the echo mem command. Somebody ought to figure out why the T400 doesn't work that way. In any event, I think this shows a confusing, piece-mealed userspace. Why can't the T400 work like the eeepc?

Anyway I am not giving up my slackware linux ever myself, because come-on, you won't be able to pry from me the ability to call 'echo mem' directly like I wanted to happen anyway. Eventually I'll write a drop in script to replace part of xfce4-session, make everything work without the nonsense that keeps changing/breaking, and keeping the family happy at the same time.

I think I would understand (and some of the frustration even) that someone using Trinity and polkit would have to make these play well together. Does Trinity use consolekit/login1 or whatever it is now called? I wish I could test what you got running over there. Right now I'm plainly using XFCE after deciding to leave behind KDE 3.5 eventually. I'm hoping a sanely designed qt style desktop... or something.

On my last few laptops, all running slackware, I could configure it to suspend on lid close with a couple of clicks in the KDE4 settings as a non-root user.

When running something other than kde, eg dwm, I never found a way to suspend without a su -c requiring me to manually enter a root password, which was irritating, but since I was running a "hardcore" WM, I could live with it.

I am going to say a real and comic fact!

I have a small internet-cafe and I have been studying a hibernate/suspend features since 06-25-13. Then I posted anHibernate Features - Simple? thread. Unfortunately, this knowledge was necessary so energy consumption is an expensive problem for me. After had been started this intense study my wife blame! She is complaining attention!!!! I showed to her my energy bill and my possible study solution. SHE laugh... Heehaw! And said: I used it in my windows easily. Is it the problem?

To summarize my experience:

* I had to manually add scripts to /etc/acpi to get the lid feature to sleep.

/etc/acpi/sleep.sh:

/etc/acpi/events/lid (calls /etc/acpi/sleep.sh):

* I had to manually add a script to get Fn-F4 to sleep. On the T400 (and most Thinkpads, I believe), Fn-F4 is the "designated" keyboard shortcut for sleep because the F4 key has a blue quarter-moon imprinted on the key.

Getting that far required a few hours on the web and the Thinkpad wiki.

As I installed /etc/acpi/sleep.sh chmod 755, any user can enable sleep with the lid or Fn-F4. Yet curiously, /sys/power/state is chmod 644 and I don't understand how sleep.sh can execute properly for non-root users.

I wanted to configure the Trinity apps klaptop daemon and tdepowersave (nee kpowersave) to execute sleep mode at a preconfigured interval, mostly for when I walk away from the laptop and forget to invoke sleep with the lid or Fn-F4. I was unable to do that until mancha provided a pkla file. Then I was able to configure at least tdepowersave to sleep at my configured interval.

On a side note, seems polkit resets /etc/polkit-1/localauthority to chmod 700. I have changed that to 755 and with each reboot the permissions are reset. I understand computer security, but I can see no reason why that directory should be forcibly reset to 700. Just basic anal behavior on the part of the polkit maintainers. I need to figure out now how to set a polkit rule/policy to stop that behavior.

My point here is to share what I had to endure to get sleep working. I don't see how anybody (with a straight face) can say this is a user-friendly procedure or that non technical users or Windows folks will find the process palatable. If I was a Windows snob and I'm not --- I seldom use Windows, I'd laugh at the complexity of what is involved.

I agree. My bewilderment is why isn't that file owned root/power with 664 permissions so non-root users who are members of the power group can change the status of that file? Why 644 root/root permissions? That's silly.

I never raised that point. I've been using Slackware for many years. Markus raised that point, and I believe, only in a tongue-in-cheek manner. :)

I admit part of the problem --- but only a very small part, could be related to the Trinity applets. That the introduction of the pkla file allowed tdepowersave to work correctly indicates the applet is using polkit and that the problem was a lack of correct policies. That said, very few Trinity users are Slackware users. As other Trinity users have not complained loudly about power saving features, either most of them are not concerned with power saving or the applets work on their distros. Therefore this could be a Slackware specific problem. I don't know and I'm only speculating. I'm not pointing fingers either. Slackware is well known for providing packages as much as the upstream maintainers intended. Further, some of the Trinity developers are Ubuntu and Debian users, where non-root usability customizing is more prevalent as well as sudo usage. All of these elements could play a role in why the Trinity applets initially failed for me. Yet that would not explain the absence of the /etc/acpi scripts or pkla file.

I think that is mixing the proverbial apples and oranges. :) This thread is very much about single-user use cases, not servers. I don't see this discussion affecting server usage. Even when two or more people concurrently use the same laptop (not physically of course, but concurrent logins), sleep mode is all about saving battery energy. Nothing more. So who cares who invokes sleep on a laptop?

Please understand I'm not demanding anything here, nor am I expecting a lobotomized Slackware. :) I'm just saying that sleep is not user-friendly for non-root users and the amount of work required to obtain basic sleep features is too much to expect from most users. Something is wrong with the entire design philosophy. Windows users expect sleep to "just work." Why should Linux users be any different?

PEBKAC. :) I have a script that syncrhonizes /etc files across 14.0 systems, with an exclude file for various files, such as rc.intet1.conf. I had forgotten to update the directory permissions on my office system, from which the synchronization is performed. :banghead: