behavior button gnome under F8

Maleki · 04-20-2008, 06:12 PM

Ok I'm using Gnome in Fedora 8 all yummed up to date. For some weird reason buttons(the picture buttons) seem to randomly stop working. It happens in Azureus, Liferea, and Nautilus. It seems to be the buttons in the top menu bar(In Nautilus it's the bar with the back,forward, stop, reload etc...). When I use a right-click menu or in Nautilus if I use the treeview on the side it seems to work. It'll start working again after a bit but I usually have to reboot to 'fix' it. Does anyone have any idea what this is?

Hardware(in case it's an issue):
A7N8X
Sempron 3000
Ati 9800se
PS2 KB
USB Mouse

Thanks in advance,

M

bgoodr · 04-21-2008, 11:06 AM

Quote:

Originally Posted by Maleki

For some weird reason buttons(the picture buttons) seem to randomly stop working. It happens in Azureus, Liferea, and Nautilus. It seems to be the buttons in the top menu bar(In Nautilus it's the bar with the back,forward, stop, reload etc...). When I use a right-click menu or in Nautilus if I use the treeview on the side it seems to work. It'll start working again after a bit but I usually have to reboot to 'fix' it. Does anyone have any idea what this is?

I do not run Fedora 8 so take this with a grain of salt. I seem to recall seeing something similar to your issue on a motherboard with a builtin video card. Sometimes single clicks would work, sometimes not. Once I stopped using that video card (disabling it in the BIOS of course), and used a separate video card, the problem disappeared. I would blame hardware first, trying out different video cards and mice first.

I did see something like this Red Hat 8 a long, long time ago, and wrote it off as a hardware glitch. The mouse click "events" were received, but the x and y coordinate that the X server received was off by 5 to 10 pixels in some random direction, such that depending upon where you actually placed the tip of the mouse pointer, the button would fire, and then sometimes not. I couldn't isolate the problem until I ran the xev utility and started poking around the edges of the xev X window to see that the X events were not getting through. In this case, I don't know what the resolution was because the hardware got scrapped anyway.

bgoodr

Maleki · 04-22-2008, 06:59 AM

The video card??? ughh... Well it makes sense if it's a hardware issue. Otherwise people would be complaining left and right about it. The video card should be solid so I'll try swapping out the motherboard tonight and see what happens (I repaired the North Bridge heat sync a while ago so...).

It's truly bizarre. I push the mouse button down. The button looks like it's pressed. I let go and it doesn't look like it's pressed any more. Fine I tell myself (except for the fact that it didn't do anything.)

It just seems so counterintuitive. Of course I'm coming from the M$ world :ducks: and we all know how intuitive _that_ can be.

Thanks,

bgoodr · 04-22-2008, 09:44 PM

Quote:

Originally Posted by Maleki

The video card??? ughh... Well it makes sense if it's a hardware issue. Otherwise people would be complaining left and right about it.

Good point. Also, try a different mouse too (actually, I should have suggested that first).

Quote:

Originally Posted by Maleki

It's truly bizarre. I push the mouse button down. The button looks like it's pressed. I let go and it doesn't look like it's pressed any more.

Yes, that is quite bizarre. Try using the xev program. What is the output when you press and hold the left button down? Is there a release event when you lift up the left mouse button? What xev does is show you the raw X events when they happen. The mouse cursor has to be in the xev window as well. The events are shown on the output of the xev program in the terminal window in which you invoke it. Even key presses are displayed. For example, for me pressing and releasing the "a" key, there are two events shown, a KeyPress and KeyRelease event:

Code:

KeyPress event, serial 30, synthetic NO, window 0x2c00001,
    root 0x155, subw 0x2c00002, time 2032620359, (35,47), root:(1031,247),
    state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XmbLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

KeyRelease event, serial 30, synthetic NO, window 0x2c00001,
    root 0x155, subw 0x2c00002, time 2032620471, (35,47), root:(1031,247),
    state 0x10, keycode 38 (keysym 0x61, a), same_screen YES,
    XLookupString gives 1 bytes: (61) "a"
    XFilterEvent returns: False

Now, we are concerned about why the mouse button is not being handled properly, so we have to determine if it is a software issue or a hardware issue. When I press and release the left mouse button, xev reports:

Code:

ButtonPress event, serial 30, synthetic NO, window 0x2c00001,
    root 0x155, subw 0x2c00002, time 2032855804, (43,42), root:(1020,718),
    state 0x10, button 1, same_screen YES

EnterNotify event, serial 30, synthetic NO, window 0x2c00001,
    root 0x155, subw 0x0, time 2032855804, (43,42), root:(1020,718),
    mode NotifyGrab, detail NotifyInferior, same_screen YES,
    focus YES, state 272

KeymapNotify event, serial 30, synthetic NO, window 0x0,
    keys:  68  0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   
           0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   0   

ButtonRelease event, serial 30, synthetic NO, window 0x2c00001,
    root 0x155, subw 0x2c00002, time 2032858305, (43,42), root:(1020,718),
    state 0x110, button 1, same_screen YES

LeaveNotify event, serial 30, synthetic NO, window 0x2c00001,
    root 0x155, subw 0x0, time 2032858305, (43,42), root:(1020,718),
    mode NotifyUngrab, detail NotifyInferior, same_screen YES,
    focus YES, state 16

The key here are the ButtonPress and ButtonRelease events. You should see a ButtonRelease event.

Also, you might try running xev from inside the fail-safe login. That might remove any window-manager (KDE, GNOME, etc.) mis-configuration that might be in play.

bgoodr