> Its pretty intrusive I'd say. And it is wrong; we'd prefer userspace > to know what we are doing; if they are told we are suspending, > userspace may be able to do something more clever than long console > switch. > > I'd prefer this not to go into mainline. So you'd prefer mainline to be broken and X to lock up ? nice ! The console switch happens -anyway- with the current code right ? So we aren't changing that. However, (even today I believe), users of /dev/apm_bios, such as X, will deadlock the VT subsystem if they get notified of the suspend before the kernel initiated console switch happen (which can happen today if the suspend is triggered by an APM application I -think- (to be verified) and will happen more once Johannes next patch gets in which fixes a regression of current APM emulation which doesn't notify user space when the suspend isn't APM originated. So this patch will fix it by console switching before notifying them, which is by far the right way to go for now. In the future, we may have smarter ways to handle that graphic subsystem (and smarter gfx drivers) and may want to provide ways to totally disable the console switching, but that's a separate issue. In fact, some distro already disable the console switch in their kernels for various reasons. But if we keep the console switch we have today, we need this patch to make it work properly and not potentially deadlock with X. Ben. _______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
