Xorg 7.5 and OpenMotif: mouse stuck in box

William Bulley web at umich.edu
Mon Oct 11 14:25:52 UTC 2010


Giuseppe Pagnoni wrote:
>
> I am resending this because it seems to me a really critical bug
> (prevents you from using OpenMotif or lesstif applications), but
> apparently nothing has been changed since last july.  Upgrading xorg
> to 1.7.7 does fix the problem, but I wonder if this may cause
> dependency problems in the ports tree.  Also, if this is the correct
> fix, is there a reason why it hasn't been integrated in the ports yet?
> 
> thanks again
>  
> giuseppe
> 
> >>>>
> I am having a problem with xorg 1.7.5 and OpenMotif resulting in the
> mouse being stuck in certain areas of the Motif windows that are
> supposed to open dialog boxes when right-clicked.  I noticed that
> somebody else reported the problem already in this list, and that it
> seems to have been fixed in xorg 1.7.7.  However xorg 1.7.7 is not yet
> available in the ports tree, nor it looks like a patch is in for the
> current version (I tried to recompile xorg today after a port tree
> update).  Is manually compiling Xorg the only solution right now?
> 
> thanks in advance for any advice
> 
> giuseppe
> 
> >>>>>

This is what I found recently.  Hope this helps you.

----- Forwarded message from William Bulley <web at umich.edu> -----

To: FreeBSD Questions <freebsd-questions at freebsd.org>
From: William Bulley <web at umich.edu>
Date: Thu, 2 Sep 2010 11:31:15 -0400
Subject: SOLVED: serious (for me) Xorg 7.5 mouse/kbd problem in 8.1-STABLE
Cc: x11 at freebsd.org, steve at freebsd.org

See below for details of solution.

----- Forwarded message from William Bulley <web at umich.edu> -----

To: FreeBSD Questions <freebsd-questions at freebsd.org>
From: William Bulley <web at umich.edu>
Date: Wed, 25 Aug 2010 07:38:34 -0400
Subject: serious (for me) Xorg 7.5 mouse/kbd problem in 8.1-STABLE

For years I have run Open-Motif on FreeBSD without issue.

I use a USB keyboard and a USB three button mouse attached to a Dell
Optiplex 960.  This combination has worked fine for the past year.

This week I upgraded from 8.0-STABLE circa January 2010 to 8.1-STABLE.
I do this by doing a buildworld/installworld sequence after csup-ing
stable-supfile and rebooting.  In this case I also pkg_deleted all of
my ports and am rebuilding them from source.  Building Xorg is one of
the very first ports I attempt since I prefer to work in xterms not
virtual terminals.

This upgrade moved me from Xorg 7.3 to Xorg 7.5, but Open-Motif stayed
the same - open-motif-2.2.3_6 - it hasn't changed in years.

After building Xorg, as root, I ran the "Xorg -configure" command to
generate my xorg.conf.new file.  Since a working /etc/X11/xorg.conf
file was still around after the upgrade from 8.0-STABLE/Xorg 7.3, I
felt no need to change anything in that file (later file comparisons
confirmed that nothing had changed).

My only relevant additions to /etc/X11/xorg.conf are these:

   Section "ServerFlags"
        Option  "AutoAddDevices" "off"
        Option  "DontZap" "false"
   EndSection

In my /etc/rc.conf file I have dbus and hald enabled, and that has
not changed since the beginning of 2010 after the confusion abated.

As a normal user, I start Xorg using /usr/local/bin/xinit as always.
I have several xterms configured in my ~/.xinitrc file.  All those
came up in the correct location and state.  I was able to open those
that started in iconic mode.  In an open/raised xterm I could enter
carriage returns and see my shell prompt move down the window.  But
when I tried to close/minimize an open/raised xterm, things failed.

I use the following keyboard/mouse combination (configured in my
.mwmrc file) to close (minimize) an xterm (and other applications):

   Shift   <Btn3Click>     window          f.minimize

This is also unchanged for some years.  This particular setting has
no bearing on the problem I came across yesterday.  I merely state
it for the record.  However, this configuration triggers the "bug".

The problem is as soon as I use that Shift/Btn3Click combination,
my arrow cursor disappears, then I cannot move to or select other
xterms - I am frozen, or locked, into the xterm I was trying to
close/minimize.  All I can do at this point is to kill(1) the
/usr/local/bin/xinit command to return to the virtual terminal
where I launched my Xorg session.

I am now reluctantly using the good old /usr/local/bin/twm which
is always built when Xorg is built from source.  I am at a loss
as to what to look for next.  I suspect Xorg, or the keyboard and
mouse driver, not the video driver, that came with.  It might be
a problem with hald(8), but again, I don't know how to debug this.

Any help with this very odd bug would be greatly appreciated.

----- End forwarded message -----

This problem is known (and fixed) in newer versions of xorg-server.

See this URL for details of the problem.

   <http://cgit.freedesktop.org/xorg/xserver/commit/?id=1884db430a5680e37e94726dff46686e2218d525>

I have also attached the changes I made to the dit/events.c file.

After rebuilding xorg-server with those patches, the Open Motif
(mwm) window manager now works with the above minimize keyboard
and mouse squence.  Thanks for all the help.

Regards,

web...

--
William Bulley                     Email: web at umich.edu

72 characters width template ----------------------------------------->|


    for (; grab; grab = grab->next)
    {
        DeviceIntPtr    gdev;
        XkbSrvInfoPtr   xkbi = NULL;
/* 3471 Mask            mask = 0; */

        gdev= grab->modifierDevice;


 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=


                }
                xE = &core;
                count = 1;
/* 3586         mask = grab->eventMask; */
            } else if (match & XI2_MATCH)
            {


 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=


                count = 1;

/* 3599          * FIXME: EventToXI2 returns NULL for enter events, so
                 * dereferencing the event is bad. Internal event types are
                 * aligned with core events, so the else clause is valid.
                 * long-term we should use internal events for enter/focus
                 * as well *
                if (xE)
                    mask = grab->xi2mask[device->id][((xGenericEvent*)xE)->evtype/8];
                else if (event->type == XI_Enter || event->type == XI_FocusIn)
                    mask = grab->xi2mask[device->id][event->type/8]; */
            } else
            {
                rc = EventToXI((InternalEvent*)event, &xE, &count);


 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=


                                "(%d, %d).\n", device->name, event->type, rc);
                    continue;
                }
/* 3618         mask = grab->eventMask; */
            }

            (*grabinfo->ActivateGrab)(device, grab, currentTime, TRUE);


 =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=


            if (xE)
            {
                FixUpEventFromWindow(device, xE, grab->window, None, TRUE);

/* 3627            TryClientEvents(rClient(grab), device, xE, count, mask, */

                   TryClientEvents(rClient(grab), device, xE, count,
                                       GetEventFilter(device, xE),
                                       GetEventFilter(device, xE), grab);
            }

            if (grabinfo->sync.state == FROZEN_NO_EVENT)

----- End forwarded message -----

Regards,

web...

--
William Bulley                     Email: web at umich.edu

72 characters width template ----------------------------------------->|


More information about the freebsd-x11 mailing list