Re: [PATCH 1/2] PM: make VT switching to the suspend console optional

[Jesse Barnes]

On 11/2/2012 4:43 PM, Alan Cox wrote:
> On Fri,  2 Nov 2012 14:43:40 -0700
> Jesse Barnes<jbarnes@xxxxxxxxxxxxxxxx>  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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/