Date: Thu, 13 Aug 2009 21:46:59 GMT From: "deeptech71@gmail.com" <deeptech71@gmail.com> To: freebsd-gnats-submit@FreeBSD.org Subject: ports/137748: "unprocessed" mouse click results in effective mouse being locked in an area Message-ID: <200908132146.n7DLkxoA045595@www.freebsd.org> Resent-Message-ID: <200908132150.n7DLo10x084550@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
>Number: 137748
>Category: ports
>Synopsis: "unprocessed" mouse click results in effective mouse being locked in an area
>Confidential: no
>Severity: serious
>Priority: low
>Responsible: freebsd-ports-bugs
>State: open
>Quarter:
>Keywords:
>Date-Required:
>Class: sw-bug
>Submitter-Id: current-users
>Arrival-Date: Thu Aug 13 21:50:01 UTC 2009
>Closed-Date:
>Last-Modified:
>Originator: deeptech71@gmail.com
>Release: -CURRENT
>Organization:
>Environment:
FreeBSD 8.0-BETA2 FreeBSD 8.0-BETA2 #0 r196086M: Sat Aug 8 17:46:05 UTC 2009 devhc@:/usr/obj/usr/src/sys/HQ i386
>Description:
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.
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200908132146.n7DLkxoA045595>