On Mon, 2012-03-26 at 12:08 -0400, Paul Fox wrote: > jerry wrote: > > On Thu, 2012-03-22 at 09:27 -0400, Paul Fox wrote: > > > jerry wrote: <snip> > > > > I feel that inhibits should not prevent the XO from dimming (think XS on > > but there's almost nothing you can do to fix that in the current > powerd codebase. unless you change the order of the timeouts, > preventing sleep will always prevent dim and blank. i'm fixing this > for 12.1.0, but it will have some repercussions -- in particular, some > activities that inhibit suspend will now dim (think Record, or a movie > player), and they'll need to do something new to prevent that as well. >
Your where I got to be with my mods. :\ > > XO here), it didn't occur to me that camera usage was being used to > > prevent the laptop from dimming. > > seems like having the laptop go to sleep while recording would be pretty > annoying. > Or watching a streaming video from the internet. > <snip> > > The reason I omitted '&& return 0' is because of seeing different > > behaviour in cpu_or_network_busy between suspended and not suspended > > that the added tracing uncovered. It's true laptop_busy works well > > but you do see that this line: > trace camera cpu_or_network_busy && return 0 > will _always_ return 0, right? so the reason for omitting it is > because it's simply wrong -- one doesn't need to observe behavior > to see that. > Sure, but it pointed me to the real cause 'check_network_activity finish' is called twice once at laptop_busy where it does prevent suspend and in the busycheck loop where it does 'break' but not 'break 2' like the other functions there do. <snip> > > > > I should of ran this trace past you first, the logged I added revealed > > the difference between the two states. Looks like my cheap hack to > > check_camera_activity was just hiding that there appears to be a need to > > break out of busycheck's 5 second loop, like inhibited_by_files does to > > restore the countdown to 15 seconds thus resetting the idle_counters. > > > > The above tracing is from last week, I have os31 installed and the > > behaviour is the same. I'll patch that if you want to see that the > > tracing is the same. > > what kind of packet is causing the wakeup? i'd like to reproduce this > on os31. > >From the above trace it clearly shows that the wakeup was wlanpacket: : @ 1332491482 got wakeup: wlanpacket @ 1332491482, slept 5 I just let the target laptop suspend for a bit and started to ping it. Why do I even bother supplying the info if your not going to read it, should I take this off-list and just file a bug instead? Jerry _______________________________________________ Testing mailing list [email protected] http://lists.laptop.org/listinfo/testing
