I am sorry if this is inappropriate for your list; if I should direct my
question to another forum, please tell me where.
I started TuxType (which is using SDL 1.2) running on a remote Debian
Linux box to be used on my local X server (running XFree86 3.3.6 under
NetBSD/i386 1.5.1_BETA).
My display flashed, became black and I had an extra large cursor. I
waited a while, but nothing else appeared. Back on the Debian box, I tried
to kill tuxtype, but it wouldn’t die until I used SIGKILL. (A /tmp/dcom*
directory was left-over.) (I am assuming that functionality for taking
over a X screen was from the SDL.)
Even though tuxtype client was not running, my X server still had the
blank black screen but now the mouse pointer wouldn’t move anymore.
How can I tell my local X server to go back to the resolution (and maybe
screen) it was currently running before?
So I can research this further, what are some keywords or terminology
describing taking over the X session (so that the resolution is changed
and the other windows are no longer visible/usable)?
(Please note that the software appears to run perfect using the local X
server on the Debian workstation.)
I can’t really answer your question as to why things were going wonky,
but, just so you know, tuxtype has a “-w” option to open in windowed
mode, instead of the default fullscreen mode. Good luck!
-bill!On Fri, Sep 07, 2001 at 11:18:12AM -0700, Jeremy C. Reed wrote:
I am sorry if this is inappropriate for your list; if I should direct my
question to another forum, please tell me where.
I started TuxType (which is using SDL 1.2) running on a remote Debian
Linux box to be used on my local X server (running XFree86 3.3.6 under
NetBSD/i386 1.5.1_BETA).
How can I tell my local X server to go back to the resolution (and maybe
screen) it was currently running before?
CTRL-ALT-plusKeyOnYourNumPad.
The ‘+’ key on the main keyboard (next to the top row of number keys)
doesn’t work for this purpose.
If that doesn’t work, then the screen is locked at that resolution. To
unlock it, run “xvidtune -unlock”, and then you should be able to change
resolutions. This will require you, of course, to have some way to run
this program. If you can’t see a terminal window on the screen, you can
try to ssh in and “export DISPLAY=:0; xvidtune -unlock”.
If the mouse isn’t moving, it’s because a program (perhaps an SDL program
that crashed without the parachute) had grabbed the input and didn’t
release it before exiting.
The fact that a buggy (or malicious!) application can do this to the
server bothers me a little…is there a historical reason for this,
anyone?
No idea, but it worries me too quite a bit - partly becaues I don’t
always have the option of doing a remote login to fix it after some
program screws up.
The reason why the feature is there seems pretty obvious to me, but I
still think there should be some ways of making it safer… At the very
least, there should be a keyboard shortcut that forces ungrabbing, built
right into the server, so that no application can disable it. Just in
case, the server should ignore applications that try to grab the input
again during one second or so after forcing ungrabbing. (Or a malicious
program could still be successful!)
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia | ----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 07 September 2001 20:33, Ryan C. Gordon wrote:
David Olofson <david.olofson at reologica.se> writes:> On Friday 07 September 2001 20:33, Ryan C. Gordon wrote:
[…]
The fact that a buggy (or malicious!) application can do this to the
server bothers me a little…is there a historical reason for this,
anyone?
No idea, but it worries me too quite a bit - partly becaues I don’t
always have the option of doing a remote login to fix it after some
program screws up.
The reason why the feature is there seems pretty obvious to me, but I
still think there should be some ways of making it safer… At the very
least, there should be a keyboard shortcut that forces ungrabbing, built
right into the server, so that no application can disable it. Just in
case, the server should ignore applications that try to grab the input
again during one second or so after forcing ungrabbing. (Or a malicious
program could still be successful!)
If you’re running an XFree86 X server, and all else fails, you can
generally do CTRL-ALT-BACKSPACE and that will kill the X server.
What happens next (which is generally reasonably benign) is then
system dependent, and recovering from that situation is left as an
exercise for the reader.
The reason why the feature is there seems pretty obvious to me, but I
still think there should be some ways of making it safer… At the very
least, there should be a keyboard shortcut that forces ungrabbing, built
right into the server, so that no application can disable it. Just in
case, the server should ignore applications that try to grab the input
again during one second or so after forcing ungrabbing. (Or a malicious
program could still be successful!)
If you’re running an XFree86 X server, and all else fails, you can
generally do CTRL-ALT-BACKSPACE and that will kill the X server.
In my case, after I killed tuxtype on the remote system with SIGKILL, my
local X server appeared to be locked up and CTRL-ALT-BACKSPACE (which
works otherwise) did not work.
Also, thanks for the suggestions and information. By the way, “-w” did
start to open tuxtype in its own window, but it never completed; the
cursor never showed inside of it, and it wouldn’t quit until I -SIGKILLed
the tuxtype client. (But maybe that is an issue for the tuxtype mailing
list if I can find one.)
It seems like an SDL-based xclient like tuxtype wouldn’t know the
difference if it is being used remotely of a network or not (since X is
network “transparent”).
If you’re running an XFree86 X server, and all else fails, you can
generally do CTRL-ALT-BACKSPACE and that will kill the X server.
Yes, that seems to work most of the time - although I’d prefer a less
brutal method.
//David Olofson — Programmer, Reologica Instruments AB
.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia | ----------------------------> http://www.linuxdj.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Friday 07 September 2001 21:42, Derrell Lipman wrote:
