From owner-freebsd-x11@FreeBSD.ORG Fri Mar 28 16:24:13 2008 Return-Path: Delivered-To: freebsd-x11@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id ECB771065670 for ; Fri, 28 Mar 2008 16:24:13 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from QMTA03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [76.96.30.32]) by mx1.freebsd.org (Postfix) with ESMTP id C1F998FC25 for ; Fri, 28 Mar 2008 16:24:13 +0000 (UTC) (envelope-from cokane@freebsd.org) Received: from OMTA07.emeryville.ca.mail.comcast.net ([76.96.30.59]) by QMTA03.emeryville.ca.mail.comcast.net with comcast id 6bUm1Z0031GXsucA30Lw00; Fri, 28 Mar 2008 16:22:16 +0000 Received: from discordia ([24.60.135.75]) by OMTA07.emeryville.ca.mail.comcast.net with comcast id 6gPv1Z00C1dmTCQ8T00000; Fri, 28 Mar 2008 16:23:56 +0000 X-Authority-Analysis: v=1.0 c=1 a=LRBUuAyMELUA:10 a=c5sTgUsrrxMA:10 a=LeH6XzfVAAAA:8 a=e5mUnYsNAAAA:8 a=6I5d2MoRAAAA:8 a=aLCJb22PslqLXWuMUrAA:9 a=X6cEPDU3Rd0jWONKJKZIGBDebQcA:4 a=zUBsD6tbDSsA:10 Received: by discordia (Postfix, from userid 103) id 6C8C51636F9; Fri, 28 Mar 2008 12:23:55 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.1.8-gr1 (2007-02-13) on discordia X-Spam-Level: X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham version=3.1.8-gr1 Received: from [172.31.1.6] (unknown [172.31.1.6]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by discordia (Postfix) with ESMTP id 4904F1636F8; Fri, 28 Mar 2008 12:23:41 -0400 (EDT) Message-ID: <47ED1AA0.80309@FreeBSD.org> Date: Fri, 28 Mar 2008 12:19:44 -0400 From: Coleman Kane Organization: The FreeBSD Project User-Agent: Thunderbird 2.0.0.12 (X11/20080312) MIME-Version: 1.0 To: Joe Marcus Clarke References: <47EA7ED2.8030406@freebsd.org> <47EB9A2B.4060203@FreeBSD.org> <47EBCED1.8060308@freebsd.org> <200803271908.34129.jkim@FreeBSD.org> <1206681177.83202.8.camel@shumai.marcuscom.com> <47ECEC78.4010200@FreeBSD.org> <1206721119.2392.12.camel@shumai.marcuscom.com> In-Reply-To: <1206721119.2392.12.camel@shumai.marcuscom.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-x11@FreeBSD.org, Jung-uk Kim Subject: Re: X pausing until mouse move (collecting commonalities) X-BeenThere: freebsd-x11@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@FreeBSD.org List-Id: X11 on FreeBSD -- maintaining and support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2008 16:24:14 -0000 Joe Marcus Clarke wrote: > On Fri, 2008-03-28 at 09:02 -0400, Coleman Kane wrote: > >> Joe Marcus Clarke wrote: >> >>> On Thu, 2008-03-27 at 19:08 -0400, Jung-uk Kim wrote: >>> >>> >>>> On Thursday 27 March 2008 12:44 pm, Joe Marcus Clarke wrote: >>>> >>>> >>>>> Coleman Kane wrote: >>>>> >>>>> >>>>>> Coleman Kane wrote: >>>>>> >>>>>> >>>>>>> Joe Marcus Clarke wrote: >>>>>>> >>>>>>> >>>>>>>> On Wed, 2008-03-26 at 16:54 -0400, Jung-uk Kim wrote: >>>>>>>> >>>>>>>> >>>>>>>>> On Wednesday 26 March 2008 12:50 pm, Joe Marcus Clarke wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>>> I'm trying to get a list of commonalities to better focus my >>>>>>>>>> troubleshooting. So far, my two machines that are affected >>>>>>>>>> have the following in common: >>>>>>>>>> >>>>>>>>>> GNOME 2.22 (with hald) >>>>>>>>>> nVidia graphics card (though different drivers) >>>>>>>>>> PS/2 mouse >>>>>>>>>> dual core >>>>>>>>>> ULE scheduler >>>>>>>>>> >>>>>>>>>> My one machine that is not affected differs from this in that >>>>>>>>>> it has an Intel graphics card, USB mouse, and is not dual >>>>>>>>>> core (but HTT). >>>>>>>>>> >>>>>>>>>> It looks like Coleman has a PS/2 mouse as well. It's >>>>>>>>>> starting to look like the mouse technology might have >>>>>>>>>> something to do with this. Anyone seeing this problem with a >>>>>>>>>> USB mouse? >>>>>>>>>> >>>>>>>>>> >>>>>>>>> I think I know why. Build xorg-server without HAL support >>>>>>>>> option and the attached patch. With HAL support (default) and >>>>>>>>> hald running, xorg-server auto-detects individual ports with >>>>>>>>> input.mouse capability even without configuration lines in >>>>>>>>> xorg.conf. If moused is enabled and USB mouse is used, >>>>>>>>> /dev/ums0 is directly used because there is a problem in MD >>>>>>>>> code (see attached patch). If moused is enabled and PS/2 >>>>>>>>> mouse is used, you end up with two input devices via >>>>>>>>> /dev/sysmouse and /dev/psm0. I couldn't find a cleaner way to >>>>>>>>> fix this problem, though. :-( >>>>>>>>> >>>>>>>>> >>>>>>>> Thanks for finding this. Here is a patch for hal which adds a >>>>>>>> mouse addon. The mouse addon polls to find whether or not >>>>>>>> moused has a given mouse device open. If it does, it sets the >>>>>>>> input device to be /dev/sysmouse instead of the actual device. >>>>>>>> Hopefully it will fix the problem without needing to disable >>>>>>>> hal support in X. I have also merged your gettimeofday >>>>>>>> patches, jkim. >>>>>>>> >>>>>>>> http://www.marcuscom.com/downloads/hal.diff >>>>>>>> >>>>>>>> Joe >>>>>>>> >>>>>>>> >>>>>>> I had to apply the attached change to your patch in order to get >>>>>>> it to work (addon/ should be addons/). Attached is the diff to >>>>>>> your diff that worked for me. >>>>>>> >>>>>>> -- >>>>>>> Coleman Kane >>>>>>> >>>>>>> >>>>>> Unfortunately, I still experience the same mouse-blocked behavior >>>>>> after applying this patch, reinstalling the port, and then >>>>>> restarting my machine (and setting the mouse device back to >>>>>> SysMouse and /dev/sysmouse in xorg.conf, and re-enabling moused). >>>>>> >>>>>> >>>>> Yeah. While the addon is doing its job, X now opens two instances >>>>> of /dev/sysmouse :-(. I still don't know why it does this when it >>>>> doesn't open two instances of /dev/psm0. >>>>> >>>>> >>>> I found why. See config/hal.c in xorg-server. It does not add Option >>>> "Device" although Linux-specific and undocumented Option "Path" for >>>> evdev is added. Thus default mouse device /dev/sysmouse is picked up. >>>> Fortunately the bug is fixed in the latest version with the following >>>> commit: >>>> >>>> http://cgit.freedesktop.org/xorg/xserver/commit/?id=47eb658e802775021e3efec109f95431cca188ca >>>> >>>> This chunk: >>>> >>>> --------- >>>> + /* most drivers use device.. not path. evdev uses both however, but the >>>> + * path version isn't documented apparently. support both for now. */ >>>> add_option(&options, "path", path); >>>> + add_option(&options, "device", path); >>>> --------- >>>> >>>> See the attached patches. >>>> >>>> >>> Ah, this explains a lot. I have also updated my hal.diff with your >>> correction, and some code to make sure that the mouse device is correct >>> when moused is running. Local tests indicate that it should do the job. >>> >>> Joe >>> >>> >> So, does this mean we should upgrade the sysutils/hald port (and other >> related ones) again? Is this in a released version? >> > > Apply http://www.marcuscom.com/downloads/hal.diff and > http://people.freebsd.org/~jkim/xorg-server.diff then rebuild hal and > xorg-server. Then reboot. All should be well again with moused/hal/X. > > Joe > Thanks, If we submit a PR on this, to fix the problem, is there a version of hald that's released which already has the fix, or should we just submit a PR with patches to both ports? -- Coleman