On Mon, Mar 15, 2010 at 6:22 PM, Peter Hutterer <[email protected]> wrote: > On Mon, Mar 15, 2010 at 05:02:46PM -0800, John Ettedgui wrote: >> On Mon, Mar 15, 2010 at 4:46 PM, Peter Hutterer >> <[email protected]> wrote: >> > On Mon, Mar 15, 2010 at 10:57:48AM -0800, John Ettedgui wrote: >> >> Hello everyone, >> >> >> >> I have had a small issue for some time with my mouse and need some help :) >> >> >> >> Basically sometimes, something bad happens (what?) and then the mouse >> >> keeps the focus on one application. >> >> For example if I am in Firefox and the mouse works there, I cannot >> >> click on anything in the task bar, or even if I alt-tab to konsole the >> >> mouse will not work there. If I right click in the console, it will >> >> behave the same way as if I was right clicking in Firefox. >> >> One "temp fix" is to right click in the application, then right click >> >> in the systray on the same application then I can click on another >> >> application and so on... >> >> This issue is usually fixed by reinstall Xorg's evdev and then restarting >> >> Xorg. >> > >> > this is almost certainly a stuck grab. If FF has an active grab, no other >> > application can receive pointer events for the duration of the grab. >> > You don't actually need to reinstall, usually restarting X is enough. In >> > fact, making the FF window unviewable will break the grab too (e.g. >> > minimising it) >> > >> > This may be an application issue or an issue with the server. To figure out >> > what exactly happens, we'd need a reproducible test case - stuck grabs are >> > notoriously tricky to debug. >> > >> > Cheers, >> > Peter >> > >> Hello Peter, >> >> in the past I believe just restarting Xorg was not enough, but I'll >> try that again next time and see. >> >> What do you mean by reproducible? Since this *seems* random it is >> quite hard for me to offer any repro. > > Usually, with stuck grabs we need to have a look at the protocol stream when > the grab activates and the events afterwards. That can then be compared > against the same stream from an older X server release that didn't exhibit > this problem to figure out what changed. Since the protocol stream results > in thousands of lines of output even for a short duration of the app, having > it run for ages often isn't an option. Also, monitoring the protocol slows > the application down, sometimes resulting in the bug not appearing when you > monitor the app. > > So we need you to help us find a way how to reproduce the issue reliably. > Since it is a grab, it's likely caused by a popup or dropdown menu or > even scrolling. If you take more attention to your actions in the next few > days, you might be able to recognise a pattern that triggers the bug. Then > you can start poking at FF to intentionally reproduce it. > > Cheers, > Peter >
So I still don't know what I did, but I got that problem yesterday as soon as Xorg was started, with only KDE and Konsole started. To fix it I really had to reinstall evdev a simple restart of Xorg would not do. Do you think that could be more of a distribution issue? I run Arch Linux, but I don't have that issue on another Arch Linux box... Thanks, John _______________________________________________ [email protected]: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
