ratpoison-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RP] Problem mit ratpoison in vnc in ratpoison


From: Joshua Neuheisel
Subject: Re: [RP] Problem mit ratpoison in vnc in ratpoison
Date: Mon, 24 Oct 2005 08:33:33 -0400
User-agent: Mozilla Thunderbird 1.0.7 (Windows/20050923)

Gerhard Siegesmund wrote:
Just a small question. I am using ratpoison on debian. To work on
another server in my network I use vnc (xtightvncviewer or xvncviewer)
to have sort of screen-like capabilities.

Now I have the following problem: If I want to for example change the
focus in the inner ratpoison, I (if I read correctly) am supposed to do:

C-t t n

which means send C-t through the outer ratpoison to the inner (C-t t),
then n to go to the next window. But it doesn't work. It seems like I
am not able to get the C-t through to the inner ratpoison? Is this a
known problem? Is there a fix for this? Did I configure something
wrong? Any hints?

I can't test this scenario, but it sounds a lot like using RP in Xnest, which works fine. Here's some debugging steps that might shed some light on the problem:

1. On your local machine ("Machine A"), start your vnc application. This will connect you to the remove machine ("Machine B").
2. Call xwininfo to get the window id of the vnc application on Machine A.
3. Call xev -id {whatever the window id was} on Machine A. This will show you the events that are reaching this window from Machine A. If you are using RP on Machine A, you may need to split the screen into frames to see both the xev output and the vnc application window at the same time.
4. Using RP on Machine A, send a C-t to RP on Machine B using "C-t t".
5. Check the output of xev.  If you see something like:
"
KeyPress event, serial 15, synthetic YES, window {window id},
state 0x4, keycode 28 (keysym 0x74, t)...
"
then you know that the RP on Machine A is actually sending the C-t. At that point, it's up to the vnc application to pass it along to RP on Machine B.

Also, you might be able to circumvent this problem if you change the modifier prefix in Machine B to something different from Machine A. This is an old GNU screen trick: C-a on one machine, C-b on another, and so on.

Joshua





reply via email to

[Prev in Thread] Current Thread [Next in Thread]