lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5094636A.9050000@virtuousgeek.org>
Date:	Fri, 02 Nov 2012 17:20:58 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
CC:	intel-gfx@...ts.freedesktop.org, linux-kernel@...r.kernel.org,
	rjw@...k.pl
Subject: 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<jbarnes@...tuousgeek.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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ