Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Wed, May 27, 2009 at 10:14:17AM +1000, Peter Hutterer wrote: On Tue, May 26, 2009 at 02:13:15PM +0100, Daniel Stone wrote: On Tue, May 26, 2009 at 01:17:15PM +1000, Peter Hutterer wrote: VT switching only works as long as the grab is asynchronous, otherwise events are queued up on the device for replaying and never pass through the XKB paths that trigger this behaviour. We should probably fix this for XKB2 by keeping a 'last internal state' separate to the normal state, which takes into account all thawed events; does that sound sensible? Then we can define 'internal actions' which take the new state field into account, or just specify that all actions are thus processed before the device is thawed. The only reason why the event's arent processed in a frozen device is because the processInputProc is changed to EnqueueEvent which does nothing but stack the events into the queue. You could hook up the VT switching and Terminate_Server actions in there (the events need to be discarded or marked used though so thawing the device doesn't switch again). Right. You still need to run them through the full XKB processing gamut however, so you can catch the state from modifiers, etc, and that requires you to run all the actions too. *shrug* I don't think there's any need for XKB2 as such, it could be fixed in the current implementation. I'll leave that as an exercise to the reader though. I didn't think you could do this within the spec, but upon re-reading, it looks like it should be possible. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, 2009-05-26 at 11:50 +1000, Peter Hutterer wrote: The main benefit of a grab in the use of menus is that you will get the next event regardless of where it occurs. This is what makes the menu disappear when you click elsewhere. If the application didn't grab, the menu could only disappear by activating a menu item, or - assuming the application supports this - by clicking elsewhere in one of the application's windows. Just as a datapoint, AFAIK that's how Windows GUI toolkits work. They don't grab the whole display, thay just wait for events in their window. Any suggestions on solving this feature through other means is appreciated (note that registering for events on every visible window doesn't count). Limiting events to the application windows doesn't seem that bad. Xav ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
Peter, Do you think that http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f38b47104a26c0524385 can/should be backed out for the time being until an alternative solution to this matter becomes available, because with this change in place in the current server, there's no real way to debug popup menu callback code during a grab where the application and the debugger are on the same display. Regards, -- Dave Peter Hutterer wrote: On Tue, May 26, 2009 at 02:13:15PM +0100, Daniel Stone wrote: On Tue, May 26, 2009 at 01:17:15PM +1000, Peter Hutterer wrote: On Tue, May 26, 2009 at 11:56:58AM +1000, David Campbell wrote: By switching to a VT, did you mean pressing CTRL-ALT-number to switch to a virtual terminal? That doesn't work for me, due to the grab. Pressing those keystrokes is unresponsive, thus for a standalone system in a location where there are no other computers, it still appears that the only option in the situation of hitting a breakpoint during a grab, is to force a power down and reboot. VT switching only works as long as the grab is asynchronous, otherwise events are queued up on the device for replaying and never pass through the XKB paths that trigger this behaviour. We should probably fix this for XKB2 by keeping a 'last internal state' separate to the normal state, which takes into account all thawed events; does that sound sensible? Then we can define 'internal actions' which take the new state field into account, or just specify that all actions are thus processed before the device is thawed. The only reason why the event's arent processed in a frozen device is because the processInputProc is changed to EnqueueEvent which does nothing but stack the events into the queue. You could hook up the VT switching and Terminate_Server actions in there (the events need to be discarded or marked used though so thawing the device doesn't switch again). I don't think there's any need for XKB2 as such, it could be fixed in the current implementation. I'll leave that as an exercise to the reader though. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Thu, May 28, 2009 at 08:30:24AM +1000, David Campbell wrote: Do you think that http://cgit.freedesktop.org/xorg/xserver/commit/?id=5e43cd28692bc05cac80f38b47104a26c0524385 can/should be backed out for the time being until an alternative solution to this matter becomes available, because with this change in place in the current server, there's no real way to debug popup menu callback code during a grab where the application and the debugger are on the same display. I don't think backing this change out is a good idea for master. xf86ProcessActionEvent is a specific API that used to be called from the kbd driver only - and this code has been removed in favour of XKB processing. A grep on my xorg/ tree shows that none of the maintained input drivers use this API now. So right now, even bringing it back doesn't help you since the kbd driver doesn't call the API anyway, and evdev never has. Indeed, time is better spent fixing this correctly - as Daniel said with a new XKB action - and hooking this action up in the right places. Owen suggested that for Qt and GDK there's workarounds to enable debugging. They don't work for you? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
Xavier Bestel wrote: The main benefit of a grab in the use of menus is that you will get the next event regardless of where it occurs. This is what makes the menu disappear when you click elsewhere. If the application didn't grab, the menu could only disappear by activating a menu item, or - assuming the application supports this - by clicking elsewhere in one of the application's windows. Just as a datapoint, AFAIK that's how Windows GUI toolkits work. They don't grab the whole display, thay just wait for events in their window. Windows isn't X. On Windows menus are a distinct class of GUI object, distinct from a Window. On X, a menu is just a window, and the application needs to use a grab if it wants to close the menu when a click occurs outside of the menu. Any suggestions on solving this feature through other means is appreciated (note that registering for events on every visible window doesn't count). Limiting events to the application windows doesn't seem that bad. That would mean that menus persist until you click in a window belonging to the application which created the menu. -- Glynn Clements gl...@gclements.plus.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, May 26, 2009 at 01:17:15PM +1000, Peter Hutterer wrote: On Tue, May 26, 2009 at 11:56:58AM +1000, David Campbell wrote: By switching to a VT, did you mean pressing CTRL-ALT-number to switch to a virtual terminal? That doesn't work for me, due to the grab. Pressing those keystrokes is unresponsive, thus for a standalone system in a location where there are no other computers, it still appears that the only option in the situation of hitting a breakpoint during a grab, is to force a power down and reboot. VT switching only works as long as the grab is asynchronous, otherwise events are queued up on the device for replaying and never pass through the XKB paths that trigger this behaviour. Hi, We should probably fix this for XKB2 by keeping a 'last internal state' separate to the normal state, which takes into account all thawed events; does that sound sensible? Then we can define 'internal actions' which take the new state field into account, or just specify that all actions are thus processed before the device is thawed. Cheers, Daniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, 26 May 2009 11:56:58 +1000 David Campbell da...@pastornet.net.au wrote: By switching to a VT, did you mean pressing CTRL-ALT-number to switch to a virtual terminal? That doesn't work for me, due to the grab. Pressing those keystrokes is unresponsive, thus for a standalone system in a location where there are no other computers, it still appears that the only option in the situation of hitting a breakpoint during a grab, is to force a power down and reboot. Do you know of any other options? Yes, bind ``chvt 1'' to an ACPI event. It's a real day saver. At least on laptops you might find Fn-key combinations that are not used otherwise. But you can use anything that emits an ACPI event, of course. Other than that, I guess you could let your screensaver call a script to switch the VT when it activates and set it to a short time-out. harry signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, May 26, 2009 at 02:13:15PM +0100, Daniel Stone wrote: On Tue, May 26, 2009 at 01:17:15PM +1000, Peter Hutterer wrote: On Tue, May 26, 2009 at 11:56:58AM +1000, David Campbell wrote: By switching to a VT, did you mean pressing CTRL-ALT-number to switch to a virtual terminal? That doesn't work for me, due to the grab. Pressing those keystrokes is unresponsive, thus for a standalone system in a location where there are no other computers, it still appears that the only option in the situation of hitting a breakpoint during a grab, is to force a power down and reboot. VT switching only works as long as the grab is asynchronous, otherwise events are queued up on the device for replaying and never pass through the XKB paths that trigger this behaviour. We should probably fix this for XKB2 by keeping a 'last internal state' separate to the normal state, which takes into account all thawed events; does that sound sensible? Then we can define 'internal actions' which take the new state field into account, or just specify that all actions are thus processed before the device is thawed. The only reason why the event's arent processed in a frozen device is because the processInputProc is changed to EnqueueEvent which does nothing but stack the events into the queue. You could hook up the VT switching and Terminate_Server actions in there (the events need to be discarded or marked used though so thawing the device doesn't switch again). I don't think there's any need for XKB2 as such, it could be fixed in the current implementation. I'll leave that as an exercise to the reader though. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
I personally wouldn't mind a kill all grabs button/key/whatever. Even if you can debug a grab issue, you don't always have the time or the right machine (debugging symbols and friends) to do it. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Mon, May 25, 2009 at 06:21:27PM -0700, Dylan McCall wrote: I wouldn't disagree that there is a problem for novice programmers, debugging a GUI app for the first time. But for these people, an obscure way to reconfigure their X server doesn't help much either. - Owen I think that debugging example is a fine example, but only a subset of the trouble today's state of mouse grabs creates. (And I get the sense David is bothered by this issue in a wider sense). The result is that a single clueless process (ANY process) can cause a user's system to lock up in a completely perplexing manner. Try troubleshooting one of these issues over the phone. (Which program were you last using?... okay... err, type ps -A...). I will add whoever solves this problem to my list of personal heroes, right up there beside Stephen Hawking. If it turns out to be a lot of people... well, I guess I'll owe a lot of beer. I think there are many people who think of this the same way. I'm sure there are many things that could be done to not have your session eaten by a hanging mouse grab if you know it will happen in advance, but the fact is something here is very, very wrong and a band-aid doesn't cut it. It's either the boatload of GUI toolkits that use mouse grabs, or the system that provides the function in the first place. The main benefit of a grab in the use of menus is that you will get the next event regardless of where it occurs. This is what makes the menu disappear when you click elsewhere. If the application didn't grab, the menu could only disappear by activating a menu item, or - assuming the application supports this - by clicking elsewhere in one of the application's windows. Any suggestions on solving this feature through other means is appreciated (note that registering for events on every visible window doesn't count). Just out of curiosity, is there something xinput 2 is doing to resolve this? (I at least get the feeling that one could rescue an inoperable pointer by plugging in a second mouse with an MPX-crazed distribution. Slightly easier to troubleshoot, maybe). core grabs in XI2/MPX are per master device only, so if you have two pointers and an app goes rogue on the core grab, you'll still be able to use the other one on all applications but the one with the grab. Same goes for keyboards. It's a bit more complicated than you describe though, since plugging a mouse in will attach it to the virtual core pointer (the default pointer) and you need a tool to create a new cursor and reattach the device. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
Owen Taylor wrote: On Tue, 2009-05-26 at 10:00 +1000, David Campbell wrote: Hi, Many/most GUI toolkits implement pop up menus using grabs. This can cause major desktop lockups when debugging GUI applications, because hitting breakpoints in pop up menu callback code will occur while a grab is active. Reaching a breakpoint while a grab is active indefinitely locks up the X server, leaving a standalone desktop user the only option but to power down and suffer potential data loss. Or kill the debugging process by switching to a VT or remotely Hi Owen, Thanks for your reply. By switching to a VT, did you mean pressing CTRL-ALT-number to switch to a virtual terminal? That doesn't work for me, due to the grab. Pressing those keystrokes is unresponsive, thus for a standalone system in a location where there are no other computers, it still appears that the only option in the situation of hitting a breakpoint during a grab, is to force a power down and reboot. Do you know of any other options? Thanks, -- Dave ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, May 26, 2009 at 03:46:12AM +0200, Maarten Maathuis wrote: I personally wouldn't mind a kill all grabs button/key/whatever. Even if you can debug a grab issue, you don't always have the time or the right machine (debugging symbols and friends) to do it. Yeah, it will come back as an XKB action. Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, May 26, 2009 at 11:56:58AM +1000, David Campbell wrote: Owen Taylor wrote: On Tue, 2009-05-26 at 10:00 +1000, David Campbell wrote: Hi, Many/most GUI toolkits implement pop up menus using grabs. This can cause major desktop lockups when debugging GUI applications, because hitting breakpoints in pop up menu callback code will occur while a grab is active. Reaching a breakpoint while a grab is active indefinitely locks up the X server, leaving a standalone desktop user the only option but to power down and suffer potential data loss. Or kill the debugging process by switching to a VT or remotely Hi Owen, Thanks for your reply. By switching to a VT, did you mean pressing CTRL-ALT-number to switch to a virtual terminal? That doesn't work for me, due to the grab. Pressing those keystrokes is unresponsive, thus for a standalone system in a location where there are no other computers, it still appears that the only option in the situation of hitting a breakpoint during a grab, is to force a power down and reboot. VT switching only works as long as the grab is asynchronous, otherwise events are queued up on the device for replaying and never pass through the XKB paths that trigger this behaviour. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
Daniel, If the kill all grabs functionality came back as an XKB action, that wouldn't help in this situation, would it, given that CTRL-ALT-number isn't working, which would seem to indicate that a synchronous grab is used? If VT switching doesn't work due to a synchronous grab, then an XKB action wouldn't either, would it? Peter Hutterer wrote: VT switching only works as long as the grab is asynchronous, otherwise events are queued up on the device for replaying and never pass through the XKB paths that trigger this behaviour. Regards, -- Dave Daniel Stone wrote: On Tue, May 26, 2009 at 03:46:12AM +0200, Maarten Maathuis wrote: I personally wouldn't mind a kill all grabs button/key/whatever. Even if you can debug a grab issue, you don't always have the time or the right machine (debugging symbols and friends) to do it. Yeah, it will come back as an XKB action. Cheers, Daniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: It's useful to have a working X server if a client holds a grab when it triggers a debugger breakpoint
On Tue, May 26, 2009 at 01:55:17PM +1000, David Campbell wrote: Daniel, If the kill all grabs functionality came back as an XKB action, that wouldn't help in this situation, would it, given that CTRL-ALT-number isn't working, which would seem to indicate that a synchronous grab is used? If VT switching doesn't work due to a synchronous grab, then an XKB action wouldn't either, would it? That is unfortunately correct. AFAICT the only reason why this ever worked was because the kbd driver switched, not the server. Peter Hutterer wrote: VT switching only works as long as the grab is asynchronous, otherwise events are queued up on the device for replaying and never pass through the XKB paths that trigger this behaviour. Regards, -- Dave Daniel Stone wrote: On Tue, May 26, 2009 at 03:46:12AM +0200, Maarten Maathuis wrote: I personally wouldn't mind a kill all grabs button/key/whatever. Even if you can debug a grab issue, you don't always have the time or the right machine (debugging symbols and friends) to do it. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
