ratpoison-devel
[Top][All Lists]
Advanced

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

[RP] Multiple heads, fdump blocks


From: Matthew Sackman
Subject: [RP] Multiple heads, fdump blocks
Date: Fri, 1 Jul 2005 23:33:28 +0100
User-agent: Mutt/1.4i

Hi,

I'm a long time user and fan of ratpoison. I've recently bought a second
monitor but each monitor is doing a different resolution and I don't
particularly want the hassle of virtual screens etc, so I was just going
to allow X to do the normal multiple displays thing.

This, as the manual says, requires :nextscreen which works well, and
certainly within each screen, the DISPLAY env is set correctly and all
seems to behave well, except for ratpoison itself.

On the second head, doing a ratpoison -c fdump just blocks, with strace:

read(3, "\1\0\t\0\0\0\0\0\337\0\0\0\0\0\0\0\1\0\0\0\f\0\0\0\330"..., 32) = 32
write(3, "\20\0\7\0\21\0\0\0RP_COMMAND_RESULTT\240\0", 28) = 28
read(3, "\1\0\n\0\0\0\0\0\340\0\0\0\0\0\0\0\1\0\0\0\f\0\0\0\330"..., 32) = 32
write(3, "\20\0\5\0\f\0\0\0RP_SELECTION", 20) = 20
read(3, "\1\0\v\0\0\0\0\0\341\0\0\0\0\0\0\0\1\0\0\0\f\0\0\0\330"..., 32) = 32
ioctl(3, FIONREAD, [0])                 = 0
write(3, "\1\0\n\0\2\0\240\0`\0\0\0\0\0\0\0\1\0\1\0\0\0\0\0\0\0\0"..., 116) = 
116
read(3, "\34\364\16\0\2\0\240\0\336\0\0\0\37\202\1\0\0\0\0\0\37"..., 32) = 32
ioctl(3, FIONREAD, [0])                 = 0
read(3, 0xbfffef40, 32)                 = -1 EAGAIN (Resource temporarily 
unavailable)
select(4, [3], NULL, NULL, NULL <unfinished ...>

However, on the second head (so DISPLAY=0:1), doing a ratpoison
--display=0:0 -c fdump does infact dump the details of the windows on
the second head.

Similarly, on the primary head (DISPLAY=0:0), ratpoison --display=0:0
-c fdump dumps the details from the primary display but ratpoison
--display=0:1 -c fdump hangs. Again, strace:

set_thread_area({entry_number:-1 -> 6, base_addr:0xb7d7b5a0, limit:1048575, 
seg_32bit:1, contents:0, read_exec_only:0, limit_in_pages:1, seg_not_present:0, 
useable:1}) = 0
munmap(0xb7fd1000, 96273)               = 0
brk(0)                                  = 0x8061000
brk(0x8082000)                          = 0x8082000
brk(0)                                  = 0x8082000
socket(PF_INET, SOCK_STREAM, IPPROTO_IP) = 3
setsockopt(3, SOL_TCP, TCP_NODELAY, [1], 4) = 0
setsockopt(3, SOL_SOCKET, SO_KEEPALIVE, [1], 4) = 0
connect(3, {sa_family=AF_INET, sin_port=htons(6001), 
sin_addr=inet_addr("0.0.0.0")}, 16) = -1 ECONNREFUSED (Connection refused)
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
rt_sigaction(SIGCHLD, NULL, {SIG_DFL}, 8) = 0
rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
nanosleep({1, 0},  <unfinished ...>

My ideal setup would be able to use rpws(pl) separately on each head so
that each monitor has its own set of workspaces. Currently, whilst
rpwspl does work on the primary head, it hangs on the secondary head and
even when using it on the primary head alone, windows seem to vanish
from the second head - create a window in the second head and C-T w
shows it; on the primary head, switch to another workspace and then back
again and now C-T w won't admit the existance of the new window, though
it is currently displayed in the second head - but cycling the windows
certainly makes it disappear for good!

This is with Debian's ratpoison 1.3.0 package on XFree86 4.3

Many thanks,

Matthew
-- 
Matthew Sackman

BOFH excuse #233:
TCP/IP UDP alarm threshold is set too low.




reply via email to

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