nanogui: Thread: how to return to framebuffer console from mwin?


[<<] [<] Page 1 of 1 [>] [>>]
Subject: how to return to framebuffer console from mwin?
From: Jun Sun ####@####.####
Date: 7 Sep 2000 00:32:22 -0000
Message-Id: <39B6E28C.9FB472E@mvista.com>

I have successfully built micro-window (an older version 0.88-ish) on
the latest tdfx frame buffer driver.  Everything seems fine.

I have one question: How do I return the fb console, where the screen
was before mwin started.

So far, I have been killing mwin apps by telneting into the box and do a
manual "kill".  However, that does not bring the console back into the
original fb console mode.

In addition, if I start next mwin app, such mterm, the keyboard input
seems lost.

Any ideas?

Thanks.

Jun
Subject: Re: how to return to framebuffer console from mwin?
From: "Greg Haerr" ####@####.####
Date: 7 Sep 2000 03:11:50 -0000
Message-Id: <008a01c01879$d8a38b40$6817dbd0@censoft.com>

: I have one question: How do I return the fb console, where the screen
: was before mwin started.

This is somewhat tricky.  The code that handles this is in
src/drivers/vtswitch.c, and is enabled by the VTSWITCH=Y
config option.  I suggest you take a look at this code, which
relies on a kernel signal being sent when the console
is switched by the kbd driver.  This code is automatically called
when the GsTerminate (MwTerminate) call is made on
Microwindows shutdown.




:
: So far, I have been killing mwin apps by telneting into the box and do a
: manual "kill".  However, that does not bring the console back into the
: original fb console mode.

Yes, there are problems in doing it this way.   I can reset the console
by then running an mwin app and exiting it with an ESC press, which
calls the MwTerminate() code.  You might need to write a small app
that just calls MwInit and then MwTerminate to reset the console buffer,
which uses the vtswitch.c code above.




:
: In addition, if I start next mwin app, such mterm, the keyboard input
: seems lost.

You can't run multiple mwin win32 apps at the present time.  All
apps must be bound into the same "server".  I've been thinking about
a shared library solution to this problem, which would be fairly
straightfwd,
but it would still run all the apps in the same process space.

Regards,

Greg





:
: Any ideas?
:
: Thanks.
:
: Jun
:
: ---------------------------------------------------------------------
: To unsubscribe, e-mail: ####@####.####
: For additional commands, e-mail: ####@####.####
:
:

[<<] [<] Page 1 of 1 [>] [>>]


Powered by ezmlm-browse 0.20.