I have a focus issue in Xorg. It seems that whenever I click in a window area that "does not process clicks well", the focus is locked on that area (forever). Examples: xterm doesn't "process clicks well" (at all, actually); after clicking in an xterm window, the focus will not follow the pointer, and when the pointer is outside the xterm window, clicks do not register at pointer location. It's the same with (the window manager's) window borders and title bars. Menu bars (like "File | Edit | View | ...") seem to "process clicks well"; after clicking a menu bar, the mouse works as usual (until bad click). I have traced the source of this issue to a USB mouse. Xorg may start with or without a USB mouse (I may plug it in later), but as long as I don't touch (input-wise) the USB mouse, using a PS/2 mouse does not produce focus locks; as soon as I move the USB mouse even a bit, the pointer (not the mice) gets cursed with the focus issue. Initially I was using KDE when (IIRC) I upgraded and rebuilt my ports. Then this focus issue occured. I thought it was a bug introduced in KDE, so I tried other window managers. Surprizingly they exhibited the same behaviour! Out of the WMs I've tested, I chose Enlightenment (from ports) because it allows me to work around the focus issue by switching to a different virtual desktop (and back) to cancel the focus lock. Here's how I currently browse the web and edit files over FTP with Konqueror: click a link or two, press ALT+F1 and ALT+F2 to switch virtual desktops in Enlightenment back and forth ("switch" for short), click the Back button, switch, click a link or two, etc.; log into an FTP server, click to traverse deeper in the directory hierarchy, select a file to open in a new tab (KWrite opens inline to edit text files), switch, click the new tab, switch, click inside the browser (text editor) area, edit text, etc.. So basically in practice I have to switch before clicking or inputting keypresses in an "area different than the last one". So this thing can render a desktop system almost unusable, if not for the special window manager. (Just to make sure that this thing is not caused by a portupgrade error, I've installed 8.0-BETA2 and the relevant packages. The issue was still there.) A search through the pr list shows a similar issue in usb/76732. I have hald started (and moused and dbus start as well), and no /etc/X1/xorg.conf.
Have you brought this up on the -ports and -x11 (and maybe -usb) mailinglists? On Thu, Aug 13, 2009 at 09:46:59PM +0000, deeptech71@gmail.com wrote: > >Number: 137748 > >Category: ports > >Synopsis: "unprocessed" mouse click results in effective mouse being locked in an area -- Edwin Groothuis Website: http://www.mavetju.org/ edwin@mavetju.org Weblog: http://www.mavetju.org/weblog/
Responsible Changed From-To: freebsd-ports-bugs->freebsd-x11 Over to maintainer(s).
Edwin Groothuis <edwin@mavetju.org> wrote: > Have you brought this up on the -ports and -x11 (and maybe -usb) mailinglists? No. I should've? Also, I did not find anyone describing these symptoms recently on -x11, -ports and -usb.
Alright, the root cause of this "bug" was a semi-broken mouse. The mouse had been physically beaten a lot, and as a result, it had a button (a so-called "universal forward button", btw) constantly pressed (ie., without the need to press the button by hand). X does not act very well with such a mouse. In other words, press-and-hold the right mouse button (or some other fancy mouse button you might have), then try to work with the mouse in X, and see what happens. Also try this on some other operating systems with X. On a side note, Windows XP works well with such a mouse: there is some (hard to describe) mouse click instability right after booting, but that goes away after a few clicks. Maybe some minor workarounds could be added to X to allow such mice to work better, but without breaking other things. This will have to be discussed with the X people. If the FreeBSD maintainers are not responsible for such changes, then: This PR can be closed. I'll also try to get all other similar bug reports (for GNU/Linux systems) out there closed.
State Changed From-To: open->closed Closed at submitter's request.