Musca not reacting predictably

Berticus · 2009-04-06 17:41:26

So I'm trying to choose between stumpwm and musca for my new window manager. I would like to really give musca a fair try, because it seems so simple, but it's not really reacting the way it's supposed to according to the documentation. For example, when I launch firefox (with vimperator), nothing is displayed. I only know it's there because I type Super+w, and it's listed in dmenu. And it seems I can't give focus to anything. For example, I'll have to xterms launched, and when they are launched they have focus. However, when I type Super+c to cycle through the windows in a current frame, it raises the window, but it doesn't give it focus. I haven't really tried splitting a frame yet, so it could just be that I can't have multiple windows in a frame, but that would also be somewhat inconvenient.

Inxsible · 2009-04-06 17:48:41

what version are you using? I am using the latest 0.9.14 and I don't have any of the mentioned problems.

are you using a musca_start file?

Last edited by Inxsible (2009-04-06 17:51:46)

Procyon · 2009-04-06 17:56:19

You have to experiment a bit with frame_display_hidden and window_open_{frame,focus}. I think there is a combination of these that will cause the behavior you described about a frame staying empty like you described. It could be a bug.

The other thing, when you cycle, what do you mean that the window is displayed but not focused?

Inxsible · 2009-04-06 18:07:34

Procyon wrote:

You have to experiment a bit with frame_display_hidden and window_open_{frame,focus}. I think there is a combination of these that will cause the behavior you described about a frame staying empty like you described. It could be a bug.
The other thing, when you cycle, what do you mean that the window is displayed but not focused?

I have been using the default values for frame_display_hidden and window_open_focus. I only changed the window_open_frame = "empty".

I think I had seen the focus issue way back in version 0.9.1, where when you cycle, it raises the window, but if you try to type something, it would type in the window that was earlier in focus -- its difficult to explain. But i haven't had that issue since 0.9.2 (I think).

Try changing the keybinding for cycle and see if it solves the problem. I use Super+Shift+c and/or Alt+Tab for cycling.

Berticus · 2009-04-06 19:47:12

I'm using latest in aur -- 0.9.14-1. I tried it both with and without a .musca_start file, and both times resulted in the same result. Fiddling around with frame_display_hidden and window_open_{frame,focus} didn't change anything.

Inxsible wrote:

I think I had seen the focus issue way back in version 0.9.1, where when you cyle, it raises the window, but if you try to type something, it would type in the window that was earlier in focus -- its difficult to explain.

I did some more investigating, and it seems what I described was wrong. The window did receive focus when it was raised, but I guess the display wasn't updated or something. Like when I type something, it would react. I just wouldn't be able to see it. Likewise, when I start firefox, it'll start, but it won't be able to show it, it'll just show what was there when it started, or something like that.

Here's an example. I start up an xterm, then another one. I try switching to the first one, and it'll do that, but the cursor isn't blinking. When I type exit, I won't see the word exit typed either. However, when I hit return, xterm will behave as expected. At this point, the current frame has only one window -- xterm. Still, with one window, it won't give me a blinking cursor, nor will it show what I'm typing, unless I hit escape. Then I can type Super+x and start firefox (with vimperator). It'll bring up xterm, because that's what was displaying when it was started, and it really is firefox, but I can't see it. If I type exit, nothing will happen, because that's not a command in vimperator. I can switch to xterm, type exit, and it'll switch back to firefox. From there I can type :xall and it will exit as expected and give me the blank screen.

From here, if I were to start firefox, firefox will look like a blank screen, instead of showing me what firefox should show me.

So I guess the best way to describe it, is the windows do get focus and raised as expected, but the display isn't updated or something like that.

Procyon · 2009-04-06 20:10:04

What happens if you start the programs from something other than Super+x?

Berticus · 2009-04-06 22:26:41

Same thing.

aerosuidae · 2009-04-07 06:00:30

A few questions:

How does dwm behave on the same system?

Can you reproduce this on any other system?

May I see xorg.conf?

May I see .xinitrc?

If this is Musca specific behavior, then it is definitely a bug and I'd like to try to reproduce it.

Berticus · 2009-04-07 11:12:39

On ratpoison, stumpwm and twm, everything works as specified. I'll try it on dwm later on today. So as far as I know, it's definitely something isolated to Musca.

xorg.conf:

Section "ServerLayout"
    Identifier     "Layout0"
    Screen      0  "Screen0" 0 0
    InputDevice    "Keyboard0" "CoreKeyboard"
    InputDevice    "Mouse0" "CorePointer"
    Option         "BlankTime" "0"
    Option         "StandbyTime" "0"
    Option         "SuspendTime" "0"
    Option         "OffTime" "0"
EndSection

Section "Files"

    ModulePath      "/usr/lib/xorg/modules"
    FontPath        "/usr/share/fonts/misc"
    FontPath        "/usr/share/fonts/TTF"
EndSection

Section "Module"
    Load           "xtrap"
    Load           "dbe"
    Load           "extmod"
    Load           "freetype"
    Load           "glx"
EndSection

Section "ServerFlags"
    Option         "Xinerama" "0"
    Option         "AutoAddDevices" "false"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Mouse0"
    Driver         "mouse"
    Option         "Protocol" "auto"
    Option         "Device" "/dev/input/mice"
    Option         "Emulate3Buttons" "no"
    Option         "ZAxisMapping" "4 5 6 7"
EndSection

Section "InputDevice"

    # generated from default
    Identifier     "Keyboard0"
    Driver         "kbd"
    Option         "AutoRepeat" "500 30"
    Option         "XkbRules" "xorg"
    Option         "XkbModel" "microsoftelite"
    Option         "XkbLayout" "us"
EndSection

Section "Monitor"

    # HorizSync source: edid, VertRefresh source: edid
    Identifier     "Monitor0"
    VendorName     "Unknown"
    ModelName      "Samsung SyncMaster"
    HorizSync       30.0 - 81.0
    VertRefresh     56.0 - 75.0
    Option         "DPMS" "off"
EndSection

Section "Device"
    Identifier     "Device0"
    Driver         "nvidia"
    VendorName     "NVIDIA Corporation"
    BoardName      "GeForce 7900 GT/GTO"
EndSection

Section "Screen"
    Identifier     "Screen0"
    Device         "Device0"
    Monitor        "Monitor0"
    DefaultDepth    24
    Option         "TwinView" "0"
    Option         "metamodes" "1280x1024_75 +0+0; 1280x1024 +0+0; 1024x768 +0+0; 800x600 +0+0; 640x480 +0+0"
    Option         "NoLogo" "true"
    Option         "AddARGBGLXVisuals" "true"
    Option         "UseEvents" "false"
    Option         "RenderAccel" "true"
    Option         "ConnectedMonitor" "DFP"
    Option         "TripleBuffer" "true"
    Option         "Coolbits" "1"
    Option         "RegisterDwords" "PerfLevelSrc=0x3333"
    SubSection     "Display"
        Depth       24
    EndSubSection
EndSection

Section "Extensions"
    Option         "Composite" "true"
EndSection

.xinitrc:

#!/bin/sh
numlockx on
xcompmgr &
# eval `cat $HOME/.fehbg`
xsetroot -cursor_name left_ptr
xset m 5 1
urxvtd -o -q -f
#exec musca
exec ratpoison
#exec twm

I've also tried it without starting xcompmgr and urxvtd.

aerosuidae · 2009-04-07 13:57:03

Berticus wrote:

On ratpoison, stumpwm and twm, everything works as specified. I'll try it on dwm later on today. So as far as I know, it's definitely something isolated to Musca.

Thanks for those files. Unfortunately, I can't reproduce the described problem on my system when using (as close as possible to) the same config.

Something else to try: activate stacking mode M+s and check if window behave differently there.

Berticus · 2009-04-08 22:49:18

I won't be able to work on this until the weekend, since I have quite a lot going on right now.

Berticus · 2009-04-12 02:31:01

For some reason I didn't think to use scrot to take a screenshot...

Anyway, as you can see, in stacking mode, the problem persists. The box in the lower left corner is firefox, the upper right is xterm, which for some reason didn't receive focus after I exited firefox.

---Edit---
The problem does not seem to exist in dwm.

Last edited by Berticus (2009-04-12 02:33:24)

moljac024 · 2009-04-12 07:50:55

Berticus wrote:

For some reason I didn't think to use scrot to take a screenshot...
http://omploader.org/tMWlndg
Anyway, as you can see, in stacking mode, the problem persists. The box in the lower left corner is firefox, the upper right is xterm, which for some reason didn't receive focus after I exited firefox.
---Edit---
The problem does not seem to exist in dwm.

Damn, that looks f'ed up!

Procyon · 2009-04-12 10:21:10

If it is halting on something, can you try strace'ing the application or musca?

Berticus · 2009-04-12 13:20:22

strace -o musca_strace musca
http://pastebin.com/mc73dba5

strace -o musca_firefox_strace firefox
http://pastebin.com/m45955532

Procyon · 2009-04-12 14:48:06

The musca log looks normal, mine has the same structure, also with lots of Resource temporarily unavailable. I didn't test with Mod4+x to start applications, I think that is where wait4() is coming from.

The firefox log is too big and complex. Can you do strace -r -o aterm.log aterm, or another small application that does it.

Berticus · 2009-04-12 16:23:14

It seems to happen with all programs using GTK2+, such as epdfview:

strace -o musca_epdfview_strace epdfview
http://pastebin.com/m6fc12f81

Procyon · 2009-04-12 17:02:08

I compared it with vimdiff to one of mine, but I don't see anything stick out.

Berticus · 2009-04-12 17:41:36

Hmm... weird. Oh well, guess I won't be using musca for the time being then. I'll definitely keep an eye out for it though.

Arch Linux

#1 2009-04-06 17:41:26

Musca not reacting predictably

#2 2009-04-06 17:48:41

Re: Musca not reacting predictably

#3 2009-04-06 17:56:19

Re: Musca not reacting predictably

#4 2009-04-06 18:07:34

Re: Musca not reacting predictably

#5 2009-04-06 19:47:12

Re: Musca not reacting predictably

#6 2009-04-06 20:10:04

Re: Musca not reacting predictably

#7 2009-04-06 22:26:41

Re: Musca not reacting predictably

#8 2009-04-07 06:00:30

Re: Musca not reacting predictably

#9 2009-04-07 11:12:39

Re: Musca not reacting predictably

#10 2009-04-07 13:57:03

Re: Musca not reacting predictably

#11 2009-04-08 22:49:18

Re: Musca not reacting predictably

#12 2009-04-12 02:31:01

Re: Musca not reacting predictably

#13 2009-04-12 07:50:55

Re: Musca not reacting predictably

#14 2009-04-12 10:21:10

Re: Musca not reacting predictably

#15 2009-04-12 13:20:22

Re: Musca not reacting predictably

#16 2009-04-12 14:48:06

Re: Musca not reacting predictably

#17 2009-04-12 16:23:14

Re: Musca not reacting predictably

#18 2009-04-12 17:02:08

Re: Musca not reacting predictably

#19 2009-04-12 17:41:36

Re: Musca not reacting predictably

Board footer