Bug#564943: scrotwm key bindings
On Mon, Apr 26 2010 at 02:30, Andrea Bolognani wrote: So, as I mentioned above, I have two X servers from stable with two different drivers and one scrotwm from testing, which connects to X server via tcp socket. So the version of Xlib (or related libraries) used by the X server is differen than the one loaded by scrotwm. As far as I understand, there is no Xlib version corresponding to a particular version of X server, they are not synchronized. By the way, if we are right and the bug is some way related to X protocol implementation, the solution may either help in migrating to xcb -- another X client library upstream developers are going to use in future releases. With “same thing”, you mean “the bug goes away”, right? Sorry.. No, the only way I got rid of the bug is starting scrotwm from a terminal with DISPLAY variable properly set. However, if we manage to make certain you’re hitting the bug only because you have an arguably not so common setup, and the same turns out to be true for Hannes, I will consider downgrading the severity of this bug. I disagree that my setup is not so common -- tcp socket is actually the second (of 2) way to connect to X server. And -- please don't forget about it -- scrotwm works well with all of my mixed library versions when started from another terminal. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Mon, Apr 26 2010 at 21:53, Dmitry Derjavin wrote: And -- please don't forget about it -- scrotwm works well with all of my mixed library versions when started from another terminal. We have a workaround! Adding 'sleep 1' before scrotwm invocation in .xsession script helps. It looks like a race condition. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
Do both of you still get the bug? Yes, still the same situation I described last time. Hannes, did you try to start scrotwm from an X terminal? It works then. I think it's fair to assume that this is some sort of startup issue as it seems to be properly initialised when run from an xterm or after switching back and forth between virtual terminals. I'm out of ideas other than that, though. Hannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
And -- please don't forget about it -- scrotwm works well with all of my mixed library versions when started from another terminal. We have a workaround! Adding 'sleep 1' before scrotwm invocation in .xsession script helps. It looks like a race condition. Unfortunately, this does not solve my issue when launching ScrotWM from Slim. I pointed Slim to a shell script which does nothing but sleep for a couple of seconds (I tried different values) and then executes ScrotWM, but the WM is still unresponsive to any keyboard input. Hannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Mon, Apr 19 2010 at 14:57, Andrea Bolognani wrote: It seems like Xorg is undergoing a lot of updates and changes, lately, so I wonder — like Hannes did — if the bug wasn’t triggered by some bug in the underlying infrastructure, with video drivers being the most likely cause due to KMS and related changes. I think it's not video drivers, because I tried to run scrotwm with two X servers -- one on Nvidia and another on ATI with the same result. In both cases it was 1:7.3+20 from stable. Scrotwm itself was installed on both stable and testing. And, by the way, 0.9.23 still has the bug. Do both of you still get the bug? Yes. Hannes, did you try to start scrotwm from an X terminal? If either of you does, I’ll get in touch with the upstream maintainer. Yes, please do it. I have no more ideas. Thanks! -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Sat, Apr 24 2010 at 15:23, Andrea Bolognani wrote: I think it's not video drivers, because I tried to run scrotwm with two X servers -- one on Nvidia and another on ATI with the same result. In both cases it was 1:7.3+20 from stable. Scrotwm itself was installed on both stable and testing. So, if I understand correctly, you have a mixed stable/testing setup, with Xorg from stable and scrotwm from testing Yes. and another one which is pure stable, except from scrotwm, which is obviously not available from stable? Yes, it is pure stable, but it acts as an X server only. All the clients, including window managers are installed on the first box, which is mixed stable/testing. So, as I mentioned above, I have two X servers from stable with two different drivers and one scrotwm from testing, which connects to X server via tcp socket. Could it be that this mixed setup is the cause of the bug? I’ve ran scrotwm on several pure testing setups, some with Intel and some other with Nvidia graphics, without hitting the bug. Today I set up a container with pure testing inside and tried to run scrotwm from it. Same thing. So, it looks like you're right -- X server upgrade may help. But now scrotwm is the only window manager I tried which does not work properly with xorg from stable. Maybe we should not work around and leave the bug unsolved, while we have a test case. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
Sorry for my long silence. Since first reporting the problem, I've done regular updates from the testing branch, of course. When I tried things out again after reading Dimitry's suggestions today, this lead to some interesting new developments: When I put scrotwm in my .xsession file and run startx, it works. Regularly, I'm using the Slim login manager for authentication and session selection. Starting ScrotWM from there resulted in the behaviour described earlier before. Now today, using the Slim login, it still seemed the same way (no keybindings working), but I could switch to a VT. This was not possible a few weeks ago. Switching back to X (even without doing anything on the VT, not even logging in), ScrotWM keybindings suddenly work as intended! So I assume part of the issue was simply caused by some temporary freak bug in an underlying X package which has been fixed by now. What remains is the weird behaviour when being run through a graphical login manager. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
On Thu, Mar 18, 2010 at 01:06:45PM +0100, Hannes wrote: Sorry for my long silence. Since first reporting the problem, I've done regular updates from the testing branch, of course. When I tried things out again after reading Dimitry's suggestions today, this lead to some interesting new developments: When I put scrotwm in my .xsession file and run startx, it works. Regularly, I'm using the Slim login manager for authentication and session selection. Starting ScrotWM from there resulted in the behaviour described earlier before. Now today, using the Slim login, it still seemed the same way (no keybindings working), but I could switch to a VT. This was not possible a few weeks ago. Switching back to X (even without doing anything on the VT, not even logging in), ScrotWM keybindings suddenly work as intended! So I assume part of the issue was simply caused by some temporary freak bug in an underlying X package which has been fixed by now. What remains is the weird behaviour when being run through a graphical login manager. I use xdm to manage my graphical logins, and I’ve encountered no problems so far; I’ve also tried starting a scrotwm session from GDM, both using the same .xsession file I use with xdm and selecting the appropriate session from the menu, and everything was still working. I will try starting scrotwm with startx and Slim too, just to be sure. It would be nice if you could try starting a scrotwm session from xdm, and also try the method outlined by Dimitry. Figuring out where the root of the problem lies isn’t easy, especially since I can’t reproduce the bug and Dimitry has outdated libraries on his box. Testing various configurations is just about the only thing to do, except for banging one’s head against the nearest wall. -- Andrea Bolognani e...@kiyuko.org Resistance is futile, you will be garbage collected. signature.asc Description: Digital signature
Bug#564943: scrotwm key bindings
On Tue, Mar 16 2010 at 23:07, Andrea Bolognani wrote: I can reproduce the bug when starting scrotwm from .xsession with xdm. But if I run it manually from any terminal with properly set $DISPLAY -- screen, xterm, VT -- it works just perfectly. Steps to reproduce: - create ~/.xsession with the only line containing 'xterm'; - log in to xdm session; - type 'scrotwm' it the xterm window. Unfortunately, as I’ve noted earlier in the bug report, I’m unable to reproduce the bug, so the only thing I can do is to collect as much info as possible and forward it upstream. I know, thank you for your time! I thought Hannes could try the steps mentioned above. Maybe it will help with his setup either. - Are you hitting this bug on amd64? No, it's pure i586 Lenny/Squeeze mixed setup. Maybe the problem is in some Lenny libraries, but unfortunately it is impossible to update the box to Squeeze now to check. Installed versions of libraries (according to ldd) scrotwm depends on: libx11-6/stable uptodate 2:1.1.5-2 libxrandr2/stable uptodate 2:1.2.3-1 libc6-i686/stable upgradeable from 2.7-18 to 2.7-18lenny2 libxcb-xlib0/stable uptodate 1.1-1.2 libxcb1/stable uptodate 1.1-1.2 libxext6/stable uptodate 2:1.0.4-1 libxrender1/stable uptodate 1:0.9.4-2 libxau6/stable uptodate 1:1.0.3-3 libxdmcp6/stable uptodate 1:1.0.2-3 - What kind of video card do you have? ATI RV280, 'radeon' driver. - How do you run scrotwm to hit the bug? from user's .xsession script, invoked by xdm. - Can you see any error in ~/.xsession-errors when you run scrotwm the “wrong” way? No. It only prints: Welcome to scrotwm V0.9.22 etc.. By the way, yes -- I've checked 0.9.22 as well. And the most interesting thing -- some time ago I faced the same problem when accidentally pressed M-S-x trying to close Iceweasel Downloads window. All Iceweasel windows disappeared and none of the key bindings worked. And now it looks like I can reproduce it: - open an Xwindow session; - start scrotwm from a terminal as described above; - start Iceweasel on an empty workplace (Important -- if there are any other windows, it doesn't work!); - download a file, Downloads window should stay opened; - make Downloads window active; - press M-S-x. Scrotwm then may be restarted from any terminal. Hope it will help. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm key bindings
I can reproduce the bug when starting scrotwm from .xsession with xdm. But if I run it manually from any terminal with properly set $DISPLAY -- screen, xterm, VT -- it works just perfectly. Steps to reproduce: - create ~/.xsession with the only line containing 'xterm'; - log in to xdm session; - type 'scrotwm' it the xterm window. -- ~dd -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#564943: scrotwm: key bindings don't work, can't switch to a VT (was: libswmhack is installed in the wrong location)
So, if the problem occurs even when libswmhack is not present, we can rule out a libswmhack problem, can't we? Yes, I think so. libswmhack only causes 'more of the same' problems if .xsession-errors is to be believed. I went for that conclusion at first, because Marco Peereboom had told me the behaviour I saw could be caused by a missing or faulty libswmhack. Unfortunately, it seems like I lack the knowledge to debug this problem, so I will ask upstream to take a look at information you reported and try to figure out where the issue lies. Ok - thanks for your effort so far! Just one last question: googling the errors around, it seems most of the people who get that kind of error (in other applications) are running on an NVIDIA card, using the NVIDIA binary drivers. If that is also the case with you, could you please try running scrotwm after switching to the free nv driver? I have an ATI video card, running with the free RadeonHD driver, so that can't be it. Hannes -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
