Re: Programs not accepting input?
On 07/21/2006 08:32, 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? 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] I think I'm seeing something similar (not sure) so I thought I'd mention it. I can repeat the effect on demand. If I open my opera browser it launches a weather widget. If I then open a terminal (aterm in this case) and give it focus, everything is good. If I bring my mouse over the widget, it appears to capture the keybaord input. My terminal cursor goes to an empty square. (My window manager is not setup to have the focus follow the mouse. I focus on clicks.) My terminal window is still highlighted as if it actually has focus. If I then click on the terminal window, or within the window in an attempt to give it focus... I still can not type in it (the cursor is still hollow). Keypresses affect the widget only at this point. The only way is to either pick a third window, or actually click in the widget, and then back to the terminal. In fact I've done the same thing with the composing of this e-mail. The focus can be stolen from this compose window in a similar fashion. I've only just started using this widget today, so this is the first time I've come across this effect. If you think this is a similar problem... and there is anything I could do to help examine it, let me know. -- Regards, Eric ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
On Sunday 23 July 2006 08:33, Greg 'groggy' Lehey wrote: One thing that IS a KDE problem is having it manage 2 distinct desktops (ie :0.0 [laptop LCD] and :0.1 [TV out]) - it occasionally decides to give the other display focus after a dialog has been closed.. Are you sure? This sounds like the issue that Peter and I have been discussing in the context of fvwm. It seems to only happen when a dialog box closes. I can tell focus moves to the other display because I tested it when I had a TV connected by pressing ctrl-esc (which pops up the 'K' menu) and the menu showed up on the TV not the LCD (where focus should have been) Which reminds me of the reason for click focus in the first place: on the machines of 15 years ago, focus following the cursor could place an unacceptable load on the X server. Maybe what we're seeing here is related. Hmm could be.. Bit hard to tell for sure where the problem lies with so many interacting pieces :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgpYHsXCEWpGJ.pgp Description: PGP signature
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: Programs not accepting input?
On Friday, 21 July 2006 at 23:38:00 +0930, Daniel O'Connor wrote: On Friday 21 July 2006 23:02, Robert Watson wrote: 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? One thing that IS a KDE problem is having it manage 2 distinct desktops (ie :0.0 [laptop LCD] and :0.1 [TV out]) - it occasionally decides to give the other display focus after a dialog has been closed.. Are you sure? This sounds like the issue that Peter and I have been discussing in the context of fvwm. Makes using kmail annoying because the only way to bring back focus is to use the mouse :( Which reminds me of the reason for click focus in the first place: on the machines of 15 years ago, focus following the cursor could place an unacceptable load on the X server. Maybe what we're seeing here is related. Greg -- See complete headers for address and phone numbers. pgpwP9gmNSdN8.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: Programs not accepting input?
On Friday 21 July 2006 23:02, Robert Watson wrote: 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? One thing that IS a KDE problem is having it manage 2 distinct desktops (ie :0.0 [laptop LCD] and :0.1 [TV out]) - it occasionally decides to give the other display focus after a dialog has been closed.. Makes using kmail annoying because the only way to bring back focus is to use the mouse :( -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C pgplv5XhRZ4x4.pgp Description: PGP signature
Re: Programs not accepting input?
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. If the target is an xterm, the cursor stays as a hollow rectangle instead of being filled - it looks like the WM knows that the window has focus but either forgets to tell the client or the client loses the message. It I leave the mouse in the target window for a while before clicking (maybe a few hundred msec) then all works correctly. I wonder if some X events are being delayed and misordered. That's mainly irritating; the problem I describe above is annoying. Did you get anywhere in debugging it? -- Peter Jeremy pgpxx2OyIpA9L.pgp Description: PGP signature
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?
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: 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: Programs not accepting input?
On Thursday, 20 July 2006 at 18:37:08 +1000, Peter Jeremy wrote: 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. If the target is an xterm, the cursor stays as a hollow rectangle instead of being filled - it looks like the WM knows that the window has focus but either forgets to tell the client or the client loses the message. It I leave the mouse in the target window for a while before clicking (maybe a few hundred msec) then all works correctly. I wonder if some X events are being delayed and misordered. Yes, this seems possible. I'd say that you're describing the same problem as I do above. That's mainly irritating; the problem I describe above is annoying. Did you get anywhere in debugging it? Not really. It seems to be happening less often now. Greg -- See complete headers for address and phone numbers. pgpeS9lBctok7.pgp Description: PGP signature
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: 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: Programs not accepting input?
Greg 'groggy' Lehey wrote: 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. There is no mouse focus. The mouse events are delivered to whatever window happens to be under the mouse pointer. Well, unless a pointer grab is in effect, but that's a separate story. 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. No, the remainder describes the case when the focus works correctly but the mapping from keycodes to keysyms gets somehow broken, so that the app gets the keyboard events but then it can't translate them into the text strings. Sorry, I couldn't look for the programs yet. -SB 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. -- Part 1.2Type: application/pgp-signature ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
hello, i followed this discussion so far and wondered what your techniques are to have your running programs accepting input again. in my case, this phenomenon heavily depends on the windowmanager you chose. when being on fluxbox and having a running instance of firefox, it every once in a while refuses keyboard input. i have had this with other gtk apps, too, for example sylpheed. to circumvent the problem and getting your application back to accept further keyboard input, i just switch workspaces back and forth and thats it, no matter on what windowmanager i am working. i never have desktops running, mostly isolated gtk apps, but from subjective experience i can tell that people running full blown gnome desktops, dont have such problems. as well as it does not seem to happen with qt apps for me. obviously, some windowmanagers dont deliver input correctly or some gtk apps have a problem with receiving a certain kind of message type. frank ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
Greg 'groggy' Lehey 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. Just a me too. I used to get this with mozilla just as you described for Firefox but haven't had it in a while (fingers crossed). This is using standard Xorg server, single head display, simple window manager (fvwm2). Some time ago I switched to the NVidia driver over the Xorg one, but I really don't know that this is related. Just that I switched some time ago and that I haven't had the lockup in a while. For all I know, I unconsciously stopped doing whatever it was that triggered the lockup :-( --Alex ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
On Mon, Mar 27, 2006 at 11:21:53AM +0200, Frank B. Scholl wrote: i followed this discussion so far and wondered what your techniques are to have your running programs accepting input again. in my case, this phenomenon heavily depends on the windowmanager you chose. when being on fluxbox and having a running instance of firefox, it every once in a while refuses keyboard input. i have had this with other gtk apps, too, for example sylpheed. to circumvent the problem and getting your application back to accept further keyboard input, i just switch workspaces back and forth and thats it, I've tried everything from switching desktops to killing fvwm2. This is how I know it's not window-manager related. As I said before, I can have two rxvts side-by-side. I focus over the left one, type, nothing appears. I focus over the right one, type, keyboard works. Focus back over the left one, nothing. Rinse, repeat. The problem happens more often with GTK apps than a plain rxvt. It's difficult to reproduce the problem, so it's nearly impossible to test. If it were more repeatable, I would have written a test client. Next time it happens, I'll try xev. But I haven't had the problem since I stopped using x11vnc. I only use the nVidia drivers and x.org. -- Rick C. Petty ___ 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
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. mike -- Mike Meyer [EMAIL PROTECTED] 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 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: Programs not accepting input?
On Sun, 2006-Mar-26 17:50:09 +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. Here's an overview (system names are simply to show that they're different machines). Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? 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. The fact that new firefox windows accept input suggests that it's somewhere in X. What X server? -- Peter Jeremy pgp61ENFPAOE4.pgp Description: PGP signature
Re: Programs not accepting input?
On Sun, 26 Mar 2006, Peter Jeremy wrote: On Sun, 2006-Mar-26 17:50:09 +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. Here's an overview (system names are simply to show that they're different machines). Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? 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. I've noticed that KDE's window manager, especially the version currently in ports, seems to occasionally have focus management problems. If I use ctrl-alt-tab to manually switch the focus, keyboard and some mouse input works properly, and after a program exits, things start working right. I think what's going on is that the window manager becomes confused as the mouse passes over the panel or interacts with the panel, as at that point the focus gets stuck. Probably because mouse input events have been grabbed and not released, which is not an unusual X window manager application bug. Once the grab has happened without a release, the mouse remains grabbed until that application exits or releases it, so that would be consistent with my triggering a release by the window manager through exiting another program and then triggering the bug again by passing over the panel (or whatever). So I'd almost certainly put this down to an X11 application bug, possibly in the window manager. The grab behavior is one of the more unfortunate ones in X11, since it allows an application to very trivially interfere with the operation of the window server as a whole, and it's an easy bug to implement (just like leaking memory -- you have an error path and forget to release all resources). Robert N M Watson ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
On Sun, Mar 26, 2006 at 11:16:36AM +, Robert Watson wrote: On Sun, 26 Mar 2006, Peter Jeremy wrote: On Sun, 2006-Mar-26 17:50:09 +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. Here's an overview (system names are simply to show that they're different machines). Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? 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. I've noticed that KDE's window manager, especially the version currently in ports, seems to occasionally have focus management problems. If I use ctrl-alt-tab to manually switch the focus, keyboard and some mouse input works properly, and after a program exits, things start working right. I I'm seeing focus problems every few months running WindowMaker, also in a 2 head configuration. The focus stick with one window - you can close that one using mouse, but you still won't be able get focus on another window. A restart of windowmaker won't help, so far I was forced doing a complete X restart whenever this happened. Not shure when it started, likely with an update from an old XFree to an Xorg release (installed xorg-6.8.2). -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
On Sun, Mar 26, 2006 at 07:17:19PM +1100, Peter Jeremy wrote: Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? My problem wasn't about focus. I know the window had input focus (my settings change the border color for focused windows), but the keyboard events weren't accepted by certain clients. 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. I've seen that problem also, with and without xinerama enabled (always with dual-head nvidia cards). My keyboard input problem only affected certain clients. Like I said, one rxvt would accept keyboard events and another rxvt right next to it wouldn't. It was an X.org server, I forget the version. I've not noticed the problem recently, but I could try to reproduce the problem if necessary. -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
On Sunday, 26 March 2006 at 19:17:19 +1100, Peter Jeremy wrote: On Sun, 2006-Mar-26 17:50:09 +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. Here's an overview (system names are simply to show that they're different machines). Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? The latter. It's not a question of focus. 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. That's mainly irritating; the problem I describe above is annoying. The fact that new firefox windows accept input suggests that it's somewhere in X. What X server? echunga: vendor string:The X.Org Foundation vendor release number:60801000 X.Org version: 6.8.1 wantadilla: vendor string:The X.Org Foundation vendor release number:60802000 X.Org version: 6.8.2 I don't think that the difference in version numbers is the issue. Greg -- See complete headers for address and phone numbers. pgpCdQYWKKAL5.pgp Description: PGP signature
Re: Programs not accepting input?
On Sunday, 26 March 2006 at 1:36:57 -0600, Rick C. Petty wrote: On Sun, Mar 26, 2006 at 05:50:09PM +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. snip One thing that the machines have in common is that they all run x2x I noticed very similar problems on both 5.4-stable and 6.0-RELEASE boxes running xorg. I've never used x2x, but I was running x11vnc, which I ended up assuming was the culprit. It's a really strange behavior-- I would have two rxvts side-by-side, one accepting keyboard input and the other I had to cut/paste text using the mouse. It was even more frustrating when it would happen in gaim mozilla windows! The same gaim process wouldn't accept keyboard input in the conversation window but the buddy window did responded to commands (e.g. control-A brought up the accounts window). Yes, this sounds quite close to what I'm experiencing. On Sunday, 26 March 2006 at 15:43:07 -0600, Rick C. Petty wrote: On Sun, Mar 26, 2006 at 07:17:19PM +1100, Peter Jeremy wrote: Is the problem that the clients aren't taking focus or have focus but aren't accepting keyboard input? My problem wasn't about focus. I know the window had input focus (my settings change the border color for focused windows), but the keyboard events weren't accepted by certain clients. 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?. Greg -- See complete headers for address and phone numbers. pgpFe3Z0Zr29L.pgp Description: PGP signature
Re: Programs not accepting input?
On Mon, 2006-Mar-27 11:29:15 +1030, Greg 'groggy' Lehey wrote: One thing that the machines have in common is that they all run x2x Can you drop this and just use a single X server? Reminder: my final question was how do I go about debugging this problem?. X11 protocol tracing (eg xmon) and client ktracing might be a start to see where the keyboard events are disappearing. -- Peter Jeremy pgpZaTj3fx9je.pgp Description: PGP signature
Re: Programs not accepting input?
[ CC'd to hackers only ] On Sun, Mar 26, 2006 at 05:50:09PM +1030, Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. snip One thing that the machines have in common is that they all run x2x I noticed very similar problems on both 5.4-stable and 6.0-RELEASE boxes running xorg. I've never used x2x, but I was running x11vnc, which I ended up assuming was the culprit. It's a really strange behavior-- I would have two rxvts side-by-side, one accepting keyboard input and the other I had to cut/paste text using the mouse. It was even more frustrating when it would happen in gaim mozilla windows! The same gaim process wouldn't accept keyboard input in the conversation window but the buddy window did responded to commands (e.g. control-A brought up the accounts window). I was baffled.. The behavior was unpredictable but sometimes repeatable. Once a window stopped accepting keyboard events, that same window would continue ignoring the keyboard until I restarted that process. At first I thought it just affected GNOME apps, but when it happened to an rxvt, I gave up and recompiled that system and stopped using x11vnc. Sorry I'm no help, but at least I feel sane knowing it wasn't just me... -- Rick C. Petty ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Programs not accepting input?
Greg 'groggy' Lehey wrote: In the last month or two I've seen increasing occurrences of programs refusing keyboard input after they've been running for a while (between hours and days). They still respond to the mouse. At first I thought it was hardware, but it happens on a number of different machines, and only with certain programs, all of them X clients. Here's an overview (system names are simply to show that they're different machines). - System echunga, running a version of the klondike game that used to come with the X distribution. - System wantadilla, running firefox. After it refuses keyboard input, I can open a new window with the mouse, and the new window accepts input. The old one still doesn't. - The same problem again with system teevee. wantadilla had what I think were hardware problems a couple of weeks ago, so I changed the entire system board and memory (but kept the disks). The new system is stable, but the problems continue. echunga and teevee have been up for months: echunga up 49+02:25, 1 user, load 0.60, 0.50, 0.35 teeveeup 100+22:08, 0 users, load 0.06, 0.31, 0.28 tvremote up 36+21:07, 0 users, load 0.18, 0.04, 0.01 wantadillaup 18+02:44, 3 users, load 0.46, 0.38, 0.49 One thing that the machines have in common is that they all run x2x (which joins X servers). echunga and wantadilla run one instance, and teevee runs another instance with tvermote, which I don't think has shown any problems. I've been running x2x for years as well, and only one of the machines has had a software upgrade anywhere near the time when the problem began. Here are the versions: FreeBSD echunga.lemis.com 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #0: Sun Feb 5 14:15:02 CST 2006 [EMAIL PROTECTED]:/usr/obj/src/FreeBSD/6-STABLE/src/sys/ECHUNGA i386 FreeBSD teevee.lemis.com 5.3-RELEASE-p5 FreeBSD 5.3-RELEASE-p5 #4: Sun Mar 13 14:58:24 CST 2005 [EMAIL PROTECTED]:/usr/obj/src/FreeBSD/TEEVEE/src/sys/TEEVEE i386 FreeBSD tvremote.lemis.com 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5 04:19:18 UTC 2004 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GENERIC i386 FreeBSD wantadilla.lemis.com 6.0-CURRENT FreeBSD 6.0-CURRENT #1: Tue Jul 12 11:57:56 CST 2005 [EMAIL PROTECTED]:/usr/obj/src/FreeBSD/6-CURRENT/src/sys/WANTADILLA i386 Does this ring a bell with anybody? Any idea how to start debugging? The fact that new firefox windows accept input suggests that it's somewhere in X. Greg Hi, Well I feel a little out of my depth here but I have been having a similar yet different problem. What I have noticed is that sometimes when I try select a running application from my KDE panel via mouse the switch does not happen. Switching in these cases will usually work via Alt-Tab however. The program being switched to seems to be functional. Maybe this is just a problem with kpanel. Like I said, I'm out of my depth here. To recover I usually end-up killing the process I tried to switch too. Even though I quite literally spend fourteen to sixteen hours per day with my FreeBSD system there is only so much a person can learn in a given period of time. This is one of those issues that for now I have simply shrugged, adjusted, and carried on with what I was doing. Here are my system details FreeBSD dwpc.dwlabs.ca 6.1-PRERELEASE FreeBSD 6.1-PRERELEASE #1: Fri Mar 24 19:34:58 AST 2006 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/DWPC-200603230410 i386 3:41AM up 1 day, 5:48, 3 users, load averages: 0.03, 0.10, 0.08 X11R6 XOrg 6.9.0, KDE 3.5 I have noticed this in 6.0-RELEASE as well I hope this is at least in some way useful. Maybe it is not even related. Other than this I have nothing more to add except that if anyone has any ideas maybe I could help test them out. --Duane ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
