From nobody@FreeBSD.org  Thu Aug 13 21:46:59 2009
Return-Path: <nobody@FreeBSD.org>
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34])
	by hub.freebsd.org (Postfix) with ESMTP id CCEE310656A8
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 13 Aug 2009 21:46:59 +0000 (UTC)
	(envelope-from nobody@FreeBSD.org)
Received: from www.freebsd.org (www.freebsd.org [IPv6:2001:4f8:fff6::21])
	by mx1.freebsd.org (Postfix) with ESMTP id BAFB28FC65
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 13 Aug 2009 21:46:59 +0000 (UTC)
Received: from www.freebsd.org (localhost [127.0.0.1])
	by www.freebsd.org (8.14.3/8.14.3) with ESMTP id n7DLkxac045596
	for <freebsd-gnats-submit@FreeBSD.org>; Thu, 13 Aug 2009 21:46:59 GMT
	(envelope-from nobody@www.freebsd.org)
Received: (from nobody@localhost)
	by www.freebsd.org (8.14.3/8.14.3/Submit) id n7DLkxoA045595;
	Thu, 13 Aug 2009 21:46:59 GMT
	(envelope-from nobody)
Message-Id: <200908132146.n7DLkxoA045595@www.freebsd.org>
Date: Thu, 13 Aug 2009 21:46:59 GMT
From: "deeptech71@gmail.com" <deeptech71@gmail.com>
To: freebsd-gnats-submit@FreeBSD.org
Subject: "unprocessed" mouse click results in effective mouse being locked in an area
X-Send-Pr-Version: www-3.1
X-GNATS-Notify:

>Number:         137748
>Category:       ports
>Synopsis:       x11/xorg: "unprocessed" mouse click results in effective mouse being locked in an area
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    freebsd-x11
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Thu Aug 13 21:50:01 UTC 2009
>Closed-Date:    Thu Sep 01 05:03:44 UTC 2011
>Last-Modified:  Thu Sep 01 05:03:44 UTC 2011
>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:

From: Edwin Groothuis <edwin@mavetju.org>
To: "deeptech71@gmail.com" <deeptech71@gmail.com>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: ports/137748: "unprocessed" mouse click results in effective mouse being locked in an area
Date: Fri, 14 Aug 2009 08:04:58 +1000

 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 
Responsible-Changed-By: linimon 
Responsible-Changed-When: Fri Aug 14 01:31:26 UTC 2009 
Responsible-Changed-Why:  
Over to maintainer(s). 

http://www.freebsd.org/cgi/query-pr.cgi?pr=137748 

From: "deeptech71@gmail.com" <deeptech71@gmail.com>
To: bug-followup@FreeBSD.org
Cc:  
Subject: Re: ports/137748: "unprocessed" mouse click results in effective 
	mouse being locked in an area
Date: Fri, 14 Aug 2009 01:46:36 +0000

 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.

From: "deeptech71@gmail.com" <deeptech71@gmail.com>
To: bug-followup@freebsd.org
Cc:  
Subject: Re: ports/137748: x11/xorg: "unprocessed" mouse click results in
 effective mouse being locked in an area
Date: Thu, 1 Sep 2011 06:27:04 +0200

 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 
State-Changed-By: linimon 
State-Changed-When: Thu Sep 1 05:03:33 UTC 2011 
State-Changed-Why:  
Closed at submitter's request. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=137748 
>Unformatted:
