It turns out that the deprecated /proc/acpi in the kernel is no longer connected to /sys/devices/*. In my case /proc/acpi and acpitool showed everything enabled, but in the /sys/devices everything was disabled. So one side was enabled and the other disabled, and as it turned out the side that mattered was not affected when applying changes to the other. Bug? Who knows - it is deprecated after all. So now I've rebuilt my kernel without the deprecated /proc/acpi support and was left with finding a way to re-enable the devices.

I wondered how hard it would be to write a bash script to simply search /sys/devices/* and present this information, with an option for toggling them. I'm not the best script writer, but I cobbled something together that appears to work, at least on two machines I own.

I figured that this script may actually be useful for others bashing their heads against their desk with this, so I figured I'd post it here in case it can help someone.

Standard disclaimer:

This library is free software; you can redistribute it and/or
modify it under the terms of the GNU Lesser General Public
License as published by the Free Software Foundation; either
version 2.1 of the License, or (at your option) any later version.

This library is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
Lesser General Public License for more details.

Use at your own risk, it may blow up your computer!

Heck, this could even work on other distros. I use gentoo primarily, I do have Ubuntu in a test partition on my laptop, but I've not tried it there. Edit: Yep, works on ubuntu.

I don't see a way to attach something, so I'll just paste it here (~434 lines):

# This script attempts to read /sys/devices/ and identify usb ports and devices
# that can be toggled to enable wakeup from sleep.
#
# Version: 2.0
# Date written: August 20, 2012
#
# Copyright (C) 2012 danomac @ gentoo forums
# Gentoo forum thread: http://forums.gentoo.org/viewtopic-t-933934.html
# The forum thread has instructions and examples on on how to use.
#
# This library is free software; you can redistribute it and/or
# modify it under the terms of the GNU Lesser General Public
# License as published by the Free Software Foundation; either
# version 2.1 of the License, or (at your option) any later version.
#
# This library is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
# Lesser General Public License for more details.

# Need to format the output differently for normal mode by adding an extra blank line
if ! $VERBOSE; then echo ""; fi
echo "*Use the Device column to identify hubs/devices to be toggled."

# If there's no results indiciate so
if [ $COUNT -eq 0 ]
then
echo ""
echo " NO USB hubs/devices found, or none are toggle-able!"
else
# Hey, we have results, show the total found
echo ""
echo "$COUNT USB hubs/devices listed."
fi

# If the dmesg hints were requested, show them
if $KERNELDMESG
then
echo "
Hints from dmesg (use this to try to identify your keyboard and mouse, you
may need to reboot to see anything relevant, see help for more info):
"

dmesg | grep ^input
fi
}

function toggleusbdevice () {
# toggleusbdevice (enabledevice:boolean, enableall:boolean, devname:string)
# First parameter is boolean. True to enable device; False to
# disable device.
# Second parameter is boolean. True to enable all relevant devices found,
# false to enable one device, specified in parameter 3.
# Third parameter is the name of the device from the Device column of list
# output

# Make sure both parameters are passed to this function!
if [ -z "$1" ]; then exit 11; fi
if [ -z "$2" ]; then exit 12; fi

# If specifying a single device to be changed, make sure parameter 3
# exists!
if ! $2
then
if [ -z "$3" ]; then exit 13; fi
fi

# Verbose detail is used throughout this function. Echo extra detail if
# requested
if $VERBOSE; then echo "Starting to parse wakeup devices found..."; fi

# Search for all wakeup files under /sys/devices
for i in `find /sys/devices -type f -name wakeup`;
do
# Extract the directory name where wakeup file resides
DEVDIRNAME=`dirname $i`

# Extract the actual device name (remove the power directory)
DEVNAME=`dirname $DEVDIRNAME`

if $VERBOSE; then echo "Does this device ($DEVPROPERNAME) look like a USB hub/device?"; fi

# Check for a product name. If none is found we most likely aren't interested in it.
if [ -e $DEVDIRNAME/../product ]
then
# If verbose output is selected, switch to full detail view
if $VERBOSE; then echo "YES!"; fi

# Some sanity checks
# Quiet and verbose can't be set at the same time
if $QUIET && $VERBOSE; then echo "You can't specify quiet (-q) and verbose (-v) at the same time."; echo ""; exit 8; fi

# Kernel DMESG can only be used with the list action
if $KERNELDMESG && (( $ACTION != 2 )); then echo "The hints from dmesg option (-k) can only be used with the list (-l) action."; echo ""; exit 9; fi

I had similar problems, when wakeup-from-LIRC failed when I moved my dedicated myth frontend to 3.3.8. I guess I found what you did, and solved it with some ugly system-specific hacks in "/etc/local.d/baslayout1.start" instead of attempting a complete script, as you did.

I'll have to take a good look at your work, as it appears to be a more general solution than mine._________________.sigs waste space and bandwidth

Yeah, works again. What doesn't, but which IIRC used to work, is waking up via mouse movement/clicking, but then again, I've got a new mouse since the last time I used that and since it's wireless (Logitech Performance MX) that might be the problem.

Quote:

You should be able to build your kernel without the deprecated /proc/acpi stuff now, I did and have no issues.

Now? I'm not using this for years now _________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Yeah, works again. What doesn't, but which IIRC used to work, is waking up via mouse movement/clicking, but then again, I've got a new mouse since the last time I used that and since it's wireless (Logitech Performance MX) that might be the problem.

Quote:

You should be able to build your kernel without the deprecated /proc/acpi stuff now, I did and have no issues.

Now? I'm not using this for years now

I remember my old Asus boards had fits when trying to make them wake up from sleep. I had so much trouble with those boards. I have an Intel board now, it's not nearly as picky. I don't remember trying to use my mouse to wake my computer - it's plugged into the same hub, maybe I'll try it at lunchtime.

I usually left the deprecated crap in the kernel because acpid needed it. It doesn't now (checked yesterday) so I finally removed it.

Edit: Nope, I can't wake up with the mouse either. I'll bet it's because the device itself is disabled. I'll look into that later.

I've updated the script with a root check. If the effective uid is not root, the script will not execute.

Also, I've been poking in to the mouse not working, and I think it's because the actual device is not enabled. udev sets the keyboard automatically now, but it apparently does not set the usb hub or mice. Strange.

I have an idea for a better script, I just have to work out details on the implementation - the script could be expanded to devices it finds that can be toggled (not necessarily just USB hubs/devices.) Not sure on the implementation part right now though.

Edit: Yep, the mouse wasn't enabled. I found it in the /sys/devices/* tree and enabled it manually and it works now.

Edit2: I've been tweaking the script to see if I can show actual USB devices (not just the hubs themselves) so they can be toggled on and off too. Making some progress.

In the meantime, since this forum doesn't allow attachments, please consider posting updates to some pastebin service, c&p here is quite tiresome.

Works, great. Only downside is it also passes the event on mouse-movement, while clicking would be my prefered way._________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

Works, great. Only downside is it also passes the event on mouse-movement, while clicking would be my prefered way.

That's not anything to do with my script or linux - the computer will wake from any activity on the USB bus, so mouse movement will wake the computer. We have loads of machines at work that behave like that.

No biggie, just found out this morning, that at least for my hardware the problem is "auto-solved". After not moving the mouse for some time, it automatically goes to standby so moving it doesn't work, but clicking does _________________++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.

There's no problem with suspending the system on keypress - a very basic script does "echo -n 'standby' >/sys/power/state" on XF86Sleep event, and that's it. Unfortunately, I'm not able to make the keyboard wake the machine up.

Having in BIOS "USB Resume from Suspend" set to "Enable" (be it together with "USB Keyboard Support" set to "Enabled" or "Disabled", it doesn't seem to matter), trying every single USB port available - still I can't wake it up (of course, any keypress on ordinary PS/2 keyboard wakes computer instantly). Maybe I'm missing some very esoteric option in kernel configuration? Maybe I could somehow bind appropriate phrase to XF86WakeUp event (but does it trigger on keypress on USB keyboard, while in "sleep" state?) - but which one, actually?

Not sure, is USB keyboard powered during "sleep", since "number lock" LED fades out while suspending. It's Omega "OK 203 Sagitta" keyboard, recognized by Linux as "Belkin". I'm using kernel 3.6.0. My USB ports are 2.0/1.1.

Any ideas, how it could be fixed?

P.S. I forgot: I noticed, that after I trigger "sleep" and wake the system up then, the "power button" doesn't switch off the system gracefully anymore. I can shut it down issuing a command - e.g. "poweroff" - but not with power button.

Yes, exactly. BTW: I'm not sure, does there exist (with newer kernels) any need to mess with /proc/acpi/wakeup. It seems, that it goes properly set "on automatic", when the rest of settings (kernel configuration and most probably udev rules) is proper. I didn't need to touch it right now, got there USB0 and USB2 "enabled", not setting anything "by hand".

Solved, anyway.

Well, solved one problem - and got two new riddles to solve after suspending and waking it up just once, it doesn't want to react on "power button" press, neither on "power off" (the one on keyboard) anymore.