possible.
-- Andrew
Signed-off-by: Andrew Johnson <[EMAIL PROTECTED]>
---
diff -rup linux-2.6.20.1/drivers/char/vt.c linux/drivers/char/vt.c
--- linux-2.6.20.1/drivers/char/vt.c2007-02-19 22:34:32.0 -0800
+++ linux/drivers/char/vt.c 2007-03-12 12:37:44.0 -0700
@@ -2
;s really up to the caller to
decide what to do if we can't switch the console - currently all callers
ignore the return code so I assume that it's okay to proceed anyway.
-- Andrew
Signed-off-by: Andrew Johnson <[EMAIL PROTECTED]>
---
diff -rup linux-2.6.20.1/drivers/char/vt.c linux
On Fri, 2007-09-03 at 21:13 +, Pavel Machek wrote:
> Hi!
>
> > > > So... if current console is graphical, we leave X accessing the
> > > > console... That's bad, because video state is not going to be
> > > > restored...?
> > >
> > > A graphical console is not necessarily X. Is there any requ
le of restoring video state on its
> own.
I realised that the previous patch would disallow a console switch while
running X. Attached is an updated patch with this scenario fixed.
Another approach might be to fail in vt_waitactive() if a console switch
is not going to occur.
-- Andrew
S
Matthew Garrett wrote:
> On Fri, Mar 09, 2007 at 10:08:05AM +0100, Pavel Machek wrote:
>
> > So... if current console is graphical, we leave X accessing the
> > console... That's bad, because video state is not going to be
> > restored...?
>
> A graphical console is not necessarily X. Is there a
Daniel Drake wrote:
> Andrew Johnson wrote:
> > When the console is in VT_AUTO/KD_GRAPHICS mode, switching to the
> > SUSPEND_CONSOLE fails, resulting in vt_waitactive() waiting
indefinately
> > or until the task is interrupted. The following patch tests if a
> >
not possible.
Signed-off-by: Andrew Johnson <[EMAIL PROTECTED]>
diff -rup linux-2.6.20.1/drivers/char/vt.c linux/drivers/char/vt.c
--- linux-2.6.20.1/drivers/char/vt.c2007-02-19 22:34:32.0 -0800
+++ linux/drivers/char/vt.c 2007-03-08 14:15:41.0 -0800
@@ -2188,10 +2
7 matches
Mail list logo