| Message ID | 1351892621-4840-2-git-send-email-jbarnes@virtuousgeek.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Fri, 2 Nov 2012 14:43:40 -0700 Jesse Barnes <jbarnes@virtuousgeek.org> wrote: > KMS drivers can potentially restore the display configuration without > userspace help. Such drivers can set a new global, pm_vt_switch, to > false if they support this feature. In that case, the PM layer won't VT > switch to the suspend console at suspend time and then back to the > original VT on resume, but rather leave things alone for a nicer looking > suspend and resume sequence. What if you are multi-head ? What are the locking rules for a suspend/kms module unload race, what happens when you load/unload and hand over multiple frame buffers ? What if you have vts split across two adapters ? Put me down as 100% in favour of the feature but we need to be a bit more careful about the implementation. The logic probably needs to be in the vt layer. I suspect we actually need a per vt flag for this, or a flag on the underlying object below the vt somewhere. So NAK for the implementation ACK for the idea. Alan
On 11/2/2012 4:43 PM, Alan Cox wrote: > On Fri, 2 Nov 2012 14:43:40 -0700 > Jesse Barnes<jbarnes@virtuousgeek.org> wrote: > >> KMS drivers can potentially restore the display configuration without >> userspace help. Such drivers can set a new global, pm_vt_switch, to >> false if they support this feature. In that case, the PM layer won't VT >> switch to the suspend console at suspend time and then back to the >> original VT on resume, but rather leave things alone for a nicer looking >> suspend and resume sequence. > > What if you are multi-head ? What are the locking rules for a suspend/kms > module unload race, what happens when you load/unload and hand over > multiple frame buffers ? What if you have vts split across two adapters ? > > Put me down as 100% in favour of the feature but we need to be a bit more > careful about the implementation. The logic probably needs to be in the > vt layer. > > I suspect we actually need a per vt flag for this, or a flag on the > underlying object below the vt somewhere. > > So NAK for the implementation ACK for the idea. Yeah good points, I didn't consider multi-head/VT split configurations at all obviously. We can probably stuff something into the VT layer for that, but how would I even configure a VT split across two adapters today? For vgacon we just route VGA to a single adapter, but I'm not sure how that works for fbcon. Does it properly support multihead? I thought not... Dunno about suspend vs unload, how do we deal that in other drivers like the disk driver for suspend for example? Overall that case seems pretty esoteric... What do you mean about hand over to multiple frame buffers? Jesse
On 11/2/2012 5:42 PM, Alan Cox wrote: >> that, but how would I even configure a VT split across two adapters >> today? For vgacon we just route VGA to a single adapter, but I'm not > > con2fb /dev/fb1 /dev/tty1 > >> Dunno about suspend vs unload, how do we deal that in other drivers like >> the disk driver for suspend for example? Overall that case seems pretty >> esoteric... >> >> What do you mean about hand over to multiple frame buffers? > > You have a global but I can insmod i915 move the consoles off it and > unload it (at least in theory - last time I tried it crashed at > least on gma500 which I need to fix 8)) i915 doesn't crash in that case, but you definitely don't get the console back as we don't restore all the VGA state. Easy enough to restore the global at least though. > > So you've got a global you can't just set back but need to adjust on > unload. > > And you've got races like suspend as we are changing framebuffer which > your code doesn't consider as you have no locking. > > If we push the logic into the vt layer we can pretty easily dump it under > the vt locks. It's not the whole story as there are all sorts of things > it doesn't handle but it does mean we can handle the case of > > "if we are switching from a vt which is on a device that doesn't need it > for suspend then do nothing" > > properly, and we can make any future features work right > > > I think all we need is consw to have a con_sw_suspend/con_sw_resume > method and the framebuffer layer to let kms get at it. yay console layer... ok I'll check it out. Overall it's probably worth some grotting around in the console layer. Avoiding a VT switch makes suspend/resume a lot nicer looking. No more blinking cursor in the corner and ugly flickering. Jesse
> that, but how would I even configure a VT split across two adapters > today? For vgacon we just route VGA to a single adapter, but I'm not con2fb /dev/fb1 /dev/tty1 > Dunno about suspend vs unload, how do we deal that in other drivers like > the disk driver for suspend for example? Overall that case seems pretty > esoteric... > > What do you mean about hand over to multiple frame buffers? You have a global but I can insmod i915 move the consoles off it and unload it (at least in theory - last time I tried it crashed at least on gma500 which I need to fix 8)) So you've got a global you can't just set back but need to adjust on unload. And you've got races like suspend as we are changing framebuffer which your code doesn't consider as you have no locking. If we push the logic into the vt layer we can pretty easily dump it under the vt locks. It's not the whole story as there are all sorts of things it doesn't handle but it does mean we can handle the case of "if we are switching from a vt which is on a device that doesn't need it for suspend then do nothing" properly, and we can make any future features work right I think all we need is consw to have a con_sw_suspend/con_sw_resume method and the framebuffer layer to let kms get at it. Alan
diff --git a/include/linux/pm.h b/include/linux/pm.h index 007e687..d8e7efb 100644 --- a/include/linux/pm.h +++ b/include/linux/pm.h @@ -35,6 +35,9 @@ extern void (*pm_idle)(void); extern void (*pm_power_off)(void); extern void (*pm_power_off_prepare)(void); +/* VT switch to the suspend console or not */ +extern bool pm_vt_switch; /* defaults to true in console.c */ + /* * Device power management */ diff --git a/kernel/power/console.c b/kernel/power/console.c index b1dc456..65376b4 100644 --- a/kernel/power/console.c +++ b/kernel/power/console.c @@ -13,9 +13,13 @@ #define SUSPEND_CONSOLE (MAX_NR_CONSOLES-1) static int orig_fgconsole, orig_kmsg; +bool pm_vt_switch = true; int pm_prepare_console(void) { + if (!pm_vt_switch) + return 0; + orig_fgconsole = vt_move_to_console(SUSPEND_CONSOLE, 1); if (orig_fgconsole < 0) return 1; @@ -26,6 +30,9 @@ int pm_prepare_console(void) void pm_restore_console(void) { + if (!pm_vt_switch) + return; + if (orig_fgconsole >= 0) { vt_move_to_console(orig_fgconsole, 0); vt_kmsg_redirect(orig_kmsg);
KMS drivers can potentially restore the display configuration without userspace help. Such drivers can set a new global, pm_vt_switch, to false if they support this feature. In that case, the PM layer won't VT switch to the suspend console at suspend time and then back to the original VT on resume, but rather leave things alone for a nicer looking suspend and resume sequence. Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org> --- include/linux/pm.h | 3 +++ kernel/power/console.c | 7 +++++++ 2 files changed, 10 insertions(+)