Re: Re: Programs not accepting input?
On Friday, 21 July 2006 at 14:32:04 +0100, Robert Watson wrote: > > On Fri, 21 Jul 2006, Greg 'groggy' Lehey wrote: > I've been keeping a closer eye on my problem. I'm using fvwm1 with click-to-focus and lose-focus-on-screen-switch. If I move from one screen to another and quickly click on a window, the border changes colour to indicate that it has focus but keyboard input is ignored. >>> >>> This is likely an fvwm1 problem. I use it too (without 2 monitors) and >>> after some time something gets broken in its focus handling, and the >>> windows stop getting focus. Restarting fvwm clears up the problem. >> >> In my case, it's erratic. I suppose I could try restarting the window >> manager next time a window freezes. > > I've occasionally also had weird focus problems with KDE. Among other > things, it looks like occasionally the mouse release event is lost > somewhere in the system (or something along these lines) -- I don't know if > it's a driver problem, a moused problem, an X11 probem, or a KDE problem. > If I press and release each of the buttons, especially the third button, > things will often recover. As long as the button is "held down", KDE > doesn't switch the focus and other events are largely ignored. Odd, eh? Indeed. Initially it doesn't look like my problems, where things hang up permanently. I've now tried the suggestion I made above, restarting the window manager. It didn't make any difference.e Greg -- See complete headers for address and phone numbers. pgpjhTUNTmmWW.pgp Description: PGP signature
Re: Re: Programs not accepting input?
On Fri, 21 Jul 2006, Greg 'groggy' Lehey wrote: I've been keeping a closer eye on my problem. I'm using fvwm1 with click-to-focus and lose-focus-on-screen-switch. If I move from one screen to another and quickly click on a window, the border changes colour to indicate that it has focus but keyboard input is ignored. This is likely an fvwm1 problem. I use it too (without 2 monitors) and after some time something gets broken in its focus handling, and the windows stop getting focus. Restarting fvwm clears up the problem. In my case, it's erratic. I suppose I could try restarting the window manager next time a window freezes. I've occasionally also had weird focus problems with KDE. Among other things, it looks like occasionally the mouse release event is lost somewhere in the system (or something along these lines) -- I don't know if it's a driver problem, a moused problem, an X11 probem, or a KDE problem. If I press and release each of the buttons, especially the third button, things will often recover. As long as the button is "held down", KDE doesn't switch the focus and other events are largely ignored. Odd, eh? Robert N M Watson Computer Laboratory University of Cambridge ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Programs not accepting input?
On Thursday, 20 July 2006 at 6:31:08 -0500, Sergey Babkin wrote: >> From: Peter Jeremy <[EMAIL PROTECTED]> > >> To resurrect a fairly old thread... >> >> On Mon, 2006-Mar-27 11:23:42 +1030, Greg 'groggy' Lehey wrote: >>> On Sunday, 26 March 2006 at 19:17:19 +1100, Peter Jeremy wrote: My work system runs separate X servers on two heads (rather than ximerama) and I have problems with windows occasionally refusing to accept focus after I move the pointer from screen to screen (though I can get an alternative window to accept focus and then switch back to the window I originally wanted). This started after an X.org upgrade but I'm not sure which one. >>> >>> Interesting. I've seen this one too: my mail window is at the left of >>> the right-hand monitor on wantadilla (:0.1). Frequently when I move >>> from :0.0 to 0:1, the window manager will highlight the window on >>> :0.1, but focus remains with some window on :0.0. If I move further >>> right and then back again, focus catches up with the correct window. >> >> I've been keeping a closer eye on my problem. I'm using fvwm1 with >> click-to-focus and lose-focus-on-screen-switch. If I move from one >> screen to another and quickly click on a window, the border changes >> colour to indicate that it has focus but keyboard input is ignored. > > This is likely an fvwm1 problem. I use it too (without > 2 monitors) and after some time something gets broken in > its focus handling, and the windows stop getting focus. > Restarting fvwm clears up the problem. In my case, it's erratic. I suppose I could try restarting the window manager next time a window freezes. >>> That's mainly irritating; the problem I describe above is annoying. >> >> Did you get anywhere in debugging it? > > BTW, I've promised Greg a script to dump the X protocol > from binary log, then I was busy and and forgot about it. > Is there still any interest in this tool? I'd certainly be interested. It would still be a challenge to catch the event that causes the freeze, though. Are you thinking of anything that ethereal can't do? Greg -- See complete headers for address and phone numbers. pgpf2gbdVWlD0.pgp Description: PGP signature
Re: Re: Re: Programs not accepting input?
>From: Peter Jeremy <[EMAIL PROTECTED]> >>BTW, I've promised Greg a script to dump the X protocol >>from binary log, then I was busy and and forgot about it. >>Is there still any interest in this tool? > >What does your script do? I've used xmon in the (distant) past but >it is designed to sit in the middle of an X connection. I think >Wireshark can decode X11. It takes a hex dump produced in whatever way (kdump, strace or maybe tcpdump) and tries to decode the X protocol fields in it. The dump can be made at either client or server side and can include both sides of transmissions (with separators between the portions of the file). Converting the output of a tracing tool into a proper raw hex dump is a separate task. I have a script that does that with output of SVR4 truss. The information about the X protocol fields gets taken from a simplistic parsing of the slightly massaged X header files. At some point I neede to trace the X protocol and I didn't know about the other tools (your e-mail is the first time I hear about them), so I've made this script. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Programs not accepting input?
>From: Peter Jeremy <[EMAIL PROTECTED]> >To resurrect a fairly old thread... > >On Mon, 2006-Mar-27 11:23:42 +1030, Greg 'groggy' Lehey wrote: >>On Sunday, 26 March 2006 at 19:17:19 +1100, Peter Jeremy wrote: >>> My work system runs separate X servers on two heads (rather than >>> ximerama) and I have problems with windows occasionally refusing to >>> accept focus after I move the pointer from screen to screen (though >>> I can get an alternative window to accept focus and then switch back >>> to the window I originally wanted). This started after an X.org >>> upgrade but I'm not sure which one. >> >>Interesting. I've seen this one too: my mail window is at the left of >>the right-hand monitor on wantadilla (:0.1). Frequently when I move >>from :0.0 to 0:1, the window manager will highlight the window on >>:0.1, but focus remains with some window on :0.0. If I move further >>right and then back again, focus catches up with the correct window. > >I've been keeping a closer eye on my problem. I'm using fvwm1 with >click-to-focus and lose-focus-on-screen-switch. If I move from one >screen to another and quickly click on a window, the border changes >colour to indicate that it has focus but keyboard input is ignored. This is likely an fvwm1 problem. I use it too (without 2 monitors) and after some time something gets broken in its focus handling, and the windows stop getting focus. Restarting fvwm clears up the problem. >>That's mainly irritating; the problem I describe above is annoying. > >Did you get anywhere in debugging it? BTW, I've promised Greg a script to dump the X protocol from binary log, then I was busy and and forgot about it. Is there still any interest in this tool? -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Programs not accepting input?
On Thu, 2006-Jul-20 06:31:08 -0500, Sergey Babkin wrote: >This is likely an fvwm1 problem. I use it too (without >2 monitors) and after some time something gets broken in >its focus handling, and the windows stop getting focus. >Restarting fvwm clears up the problem. I've seen that as well and I'm fairly certain it's a different bug. Grog reports a similar problem to mine and (in my case) it seems to be just something being too slow - fvwm continues running correctly. >>>That's mainly irritating; the problem I describe above is annoying. >> >>Did you get anywhere in debugging it? > >BTW, I've promised Greg a script to dump the X protocol >from binary log, then I was busy and and forgot about it. >Is there still any interest in this tool? What does your script do? I've used xmon in the (distant) past but it is designed to sit in the middle of an X connection. I think Wireshark can decode X11. -- Peter Jeremy pgpeoYIvy0spc.pgp Description: PGP signature
Re: Re: Programs not accepting input?
>Same here. As mentioned in the original message, I can use the mouse >to open a new window under firefox. The new window will accept >keyboard input, the old one won't. It's almost as if it's deadlocking >on input. > >Reminder: my final question was "how do I go about debugging this >problem?". Does it happen with any kind of programs? If yes, can you reproduce it with "xev"? If yes, it would probably be something focus-related (and you'd be able to see that the Focus event is not coming in). The focus management and the highlighting of the window manager decoration are not physically connected in any way, so a bug in the window manager might cause it to do the highlighting but forget to give the focus to the application. To debug that you can add debugging printout to the WM. Or I've had a script that sort of decoded the X protocol, so if you can get the dump of these (maybe with ktrace), you can decode the dump and see what happens with the focus. I'll look for it in my archives. If no, it might be something with the keyboard event translation to keysyms/text. You can debug this by writing a test program that would do it own dispatch loop - i.e. call XEvent() and then XtDispatchEvent() (or some close names - I might not remember them right), and print the debugging messages. So if you see that XEvent() is getting events but then nothing comes out of dispatching them, then the translation is broken somewhere. I might be able to find this kind of a program in my archives too, I'll look around. BTW, one place where the keyboard events might disappear is the Input Method handling code. But I don't think that you run any Input Methods. -SB ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Programs not accepting input?
On Monday, 27 March 2006 at 20:30:52 -0500, Mike Meyer wrote: > In <[EMAIL PROTECTED]>, Greg 'groggy' Lehey <[EMAIL PROTECTED]> typed: >>> The focus management and the highlighting of the window manager >>> decoration are not physically connected in any way, so a bug in the >>> window manager might cause it to do the highlighting but forget to >>> give the focus to the application. >> But mouse focus and keyboard focus are the same, right? > > There isn't a "mouse focus". Mouse events are tied to window they > happen in, not the one with focus. If you use a window manager that > doesn't change the keyboard focus on mouse events, it's possible to > have mouse events happen in a window that doesn't have the focus. Ah, good to know. That changes things somewhat. Greg -- See complete headers for address and phone numbers. pgpXBFQQPhFVN.pgp Description: PGP signature
Re: Re: Programs not accepting input?
In <[EMAIL PROTECTED]>, Greg 'groggy' Lehey <[EMAIL PROTECTED]> typed: > > The focus management and the highlighting of the window manager > > decoration are not physically connected in any way, so a bug in the > > window manager might cause it to do the highlighting but forget to > > give the focus to the application. > But mouse focus and keyboard focus are the same, right? There isn't a "mouse focus". Mouse events are tied to window they happen in, not the one with focus. If you use a window manager that doesn't change the keyboard focus on mouse events, it's possible to have mouse events happen in a window that doesn't have the focus. http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Re: Programs not accepting input?
On Monday, 27 March 2006 at 7:03:23 -0600, Sergey Babkin wrote: >> Same here. As mentioned in the original message, I can use the mouse >> to open a new window under firefox. The new window will accept >> keyboard input, the old one won't. It's almost as if it's deadlocking >> on input. >> >> Reminder: my final question was "how do I go about debugging this >> problem?". > > Does it happen with any kind of programs? No. So far I've only seen it with firefox, emacs and kklondike. > If yes, it would probably be something focus-related (and you'd be > able to see that the Focus event is not coming in). As already mentioned, this is not the case. I've seen this kind of problem too. > The focus management and the highlighting of the window manager > decoration are not physically connected in any way, so a bug in the > window manager might cause it to do the highlighting but forget to > give the focus to the application. But mouse focus and keyboard focus are the same, right? The windows respond to the mouse, but not to the keyboard. The remainder of your reply seems to build on the assumption that there is no focus. I'll leave it there in case I misunderstood and you want to refer to it. > To debug that you can add debugging printout to the WM. Or I've had > a script that sort of decoded the X protocol, so if you can get the > dump of these (maybe with ktrace), you can decode the dump and see > what happens with the focus. I'll look for it in my archives. > > If no, it might be something with the keyboard event translation to > keysyms/text. You can debug this by writing a test program that > would do it own dispatch loop - i.e. call XEvent() and then > XtDispatchEvent() (or some close names - I might not remember them > right), and print the debugging messages. So if you see that > XEvent() is getting events but then nothing comes out of dispatching > them, then the translation is broken somewhere. > > I might be able to find this kind of a program > in my archives too, I'll look around. thanks. > BTW, one place where the keyboard events might disappear is the > Input Method handling code. But I don't think that you run any Input > Methods. Not explicitly. Greg -- See complete headers for address and phone numbers. pgpKxcplWbAnS.pgp Description: PGP signature
