Re: [PATCH 1/2] PM: make VT switching to the suspend console optional
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: make VT switching to the suspend console optional
> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: make VT switching to the suspend console optional
On 11/2/2012 4:43 PM, Alan Cox wrote: On Fri, 2 Nov 2012 14:43:40 -0700 Jesse Barnes 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] PM: make VT switching to the suspend console optional
On Fri, 2 Nov 2012 14:43:40 -0700 Jesse Barnes 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
