daniel -- problems noted. i agree with the team that increasing the timeout to a minutes seems prudent for the time being. i have some ideas on how to make inhibiting suspend more robust, and i've been working on the dcon issue(s) (#9631, #9664) in the last day or so.
daniel wrote: > Laptops have not yet been handed out here in La Rioja, but a few have > been handed around to various parts of the MinEd and support staff, so > we're already seeing some bug reports and user experiences rolling in. > > The idle-suspend experience has been causing some discomfort. > Specifically 4 cases: > > 1. The machine suspended while playing a video in Jukebox (probably > not a common case, but it happened, and I had to explain this system, > and it's not something that's very easy to explain to non-techies!) i'm quite interested in this one, because it's one i really thought shouldn't happen. > > 2. The machine suspends frequently while it is loading a web page, and > does not wake up, meaning that the web page doesn't finish loading > until you realise what's happened and intervene i'm going to venture a guess that the network there isn't quite as responsive as it is here at 1cc. right now we inhibit based mostly on outbound network traffic within 5 seconds of the suspend point. in the case of slow DNS or web-server response, i can imagine that that might not be sufficient. the mechanics within powerd for doing the detection are a little cumbersome right now -- i think i know how to fix it, but it's non-trivial. if i can rework it, it will be much easier (i hope) to extend the detection interval. > > 3. After a lid-suspend, the machine frequently sleeps before it has > scanned or reconnected for wireless networks. The user sits there > waiting and waiting for the network to appear again, and it's not > going to appear until they realise what's happened and intervene. > (related #9854, but I feel that this is a more general problem) i'll try and find a way to detect that we're in the "associating" phase. this one has hit me, too, and i agree it's very annoying to realize you're waiting for something that's never going to happen. paul > > 4. Sometimes a stale version of the screen is loaded as the machine > goes into suspend - generally the screen that was locked upon the > previous suspend. This is really confusing for the user. (#9664) > > > As a result of these early issues, the team here wanted to increase > the idle suspend timeout from 15 seconds to 15 minutes. I managed to > persuade them not to do this until we've actually seen how it holds up > in the hands of actual users (children) but in the mean time they will > be increasing that timeout to 60 seconds in order to soften the blow. > > Daniel > _______________________________________________ > Devel mailing list > Devel@lists.laptop.org > http://lists.laptop.org/listinfo/devel =--------------------- paul fox, p...@laptop.org _______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel