On 01/21/2012 11:49 AM, Alan Stern wrote:
On Fri, 20 Jan 2012, Konstantin Svist wrote:
There is still some weird behavior I want to ask about:
While testing the dongle on the 'problematic' machine, I have to run
both "echo USB#>/proc/acpi/wakeup" and "echo enabled>
/sys/bus/usb/devices/3-1/power/wakeup" to get the dongle to wake from
/proc/acpi/wakeup is deprecated. Instead you should do something like
"echo enabled>/sys/bus/usb/devices/usb3/../power/wakeup". In recent
kernels this has now become the default, so you shouldn't have to do
this step at all.
Yup. Now that Fedora rolled out 3.2 series kernels, this is indeed the
behavior. In 3.1, I had to do this step.
remote button press. But when I try it on my laptop, "echo
USB1>/proc/acpi/wakeup" is enough and
/sys/bus/usb/devices/3-1/power/wakeup doesn't do anything -- and the
laptop wakes no matter which button was pressed on the remote.
I'm confused by your description. Firstly, is the dongle's sysfs path
3-1 on both machines? Secondly, what button presses on the remote will
wake up the problematic machine? Thirdly, did you check whether the
dongle's behavior is the same regardless of whether
/sys/bus/usb/devices/3-1/power/wakeup contains "enabled" or "disabled"?
I'm confused, too ;)
1 Yes, the dongle's sysfs happens to be 3-1 on both machines most of the
time. It changes if I re-plug it into a different port, but I'm just
trying to simplify it here.
2 Problematic machine (a.k.a. my HTPC) wakes up on ambient light and on
"power" button from remote
Now that I'm using kernel 3.2, I've got bigger problems:
* Laptop suspends fine but doesn't wake from the dongle. I've checked
that /sys/bus...wakeup is enabled - but no reaction. If I boot to 3.1.9
the old behavior comes back (wake on any dongle remote's keypress)
* The HTPC doesn't even want to suspend as long as /sys/bus...wakeup is
enabled for the dongle. It resumes instantly and wakeup setting is set
to "disabled"
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
