After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 599914 - settings daemon locked up when attaching new monitor
settings daemon locked up when attaching new monitor
Status: RESOLVED FIXED
Product: gnome-desktop
Classification: Core
Component: libgnome-desktop
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Desktop Maintainers
Desktop Maintainers
Depends on:
Blocks:
 
 
Reported: 2009-10-28 14:47 UTC by William Jon McCann
Modified: 2010-03-30 21:09 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
bt (3.78 KB, text/plain)
2009-10-28 14:47 UTC, William Jon McCann
  Details
patch to ignore error (496 bytes, patch)
2009-11-08 21:03 UTC, William Jon McCann
none Details | Review
Ignore errors when setting the monitor size fails (949 bytes, patch)
2010-03-09 11:06 UTC, Bastien Nocera
committed Details | Review

Description William Jon McCann 2009-10-28 14:47:51 UTC
Created attachment 146426 [details]
bt

Ajax did a scratch build of the intel driver to try to fix
https://bugzilla.redhat.com/show_bug.cgi?id=531318

The fix worked as expected on bootup.  The closed internal did not display
output.  However, after logging in and opening the lid the displays stopped
updating.  GSD was hung up.  I'm attaching a backtrace of GSD when it is in
that state.
Comment 1 William Jon McCann 2009-10-28 15:24:23 UTC
On stderr I get:
The error was 'BadMatch (invalid parameter attributes)'.
  (Details: serial 2564 error_code 8 request_code 147 minor_code 7)
  (Note to programmers: normally, X errors are reported asynchronously;
   that is, you will receive the error a while after causing it.
   To debug your program, run it with the --sync command line
   option to change this behavior. You can then get a meaningful
   backtrace from your debugger if you break on the gdk_x_error() function.)
Comment 2 Federico Mena Quintero 2009-10-29 00:57:53 UTC
Even though gnome-rr and the client tools do the best they can to ensure that they are sending valid values to the XRR*() API, sometimes we get a BadMatch like that.

It sounds like crtc_assignment_apply() should push a GDK X error handler and just return a suitable GError if an error happens.

However, I'm curious as to what exactly caused the BadMatch... would it be horribly hard to track down that code in the X server?  Since you have Ajax at hand, could he do it? :)
Comment 3 William Jon McCann 2009-11-08 21:03:33 UTC
Created attachment 147228 [details] [review]
patch to ignore error

Something like this?
Comment 4 Adam Jackson 2009-11-09 15:03:22 UTC
The BadMatch is coming from near the top of ProcRRSetScreenSize():

    for (i = 0; i < pScrPriv->numCrtcs; i++)
    {
        RRCrtcPtr   crtc = pScrPriv->crtcs[i];
        RRModePtr   mode = crtc->mode;
        if (mode)
        {
            int         source_width = mode->mode.width;
            int         source_height = mode->mode.height;
            Rotation    rotation = crtc->rotation;

            if (rotation == RR_Rotate_90 || rotation == RR_Rotate_270)
            {
                source_width = mode->mode.height;
                source_height = mode->mode.width;
            }

            if (crtc->x + source_width > stuff->width ||
                crtc->y + source_height > stuff->height)
            return BadMatch;
        }
    }

Where, as always, "stuff" is the current request buffer.  In other words, you've got an existing CRTC config where the total size already in use is larger than the size you're trying to request.
Comment 5 Federico Mena Quintero 2009-11-11 11:45:04 UTC
Wait, but why do we even go into "if (mode)"?  The code in gnome-rr-config.c looks like

crtc_assignment_apply ()
{
  foreach (crtc in all_crtcs) {
    if (crtc->mode != NULL)
      XRRSetCrtcConfig (crtc, 0, 0, 0, 0, 0, 0, 0); /* unset the mode */
  }

  XRRSetScreenSize (new_width, new_height);

  foreach (crtc in all_crtcs) {
     XRRSetCrtcConfig (crtc, new parameters);
  }
}

That is, we turn off all crtcs that have a mode set and reset them to (0, 0) offsets, *then* we set the screen size, and finally we set the crtcs to the proper configuration.

As far as I can tell, this is the same that xrandr(1) does.  Or are we failing to reset some CRTC?  (Is it possible to know the crtc in question, so that we can then see what the gnome code is smoking?)

Jon, can you get a debug build of gnome-settings-daemon and gnome-desktop?  -O0 -g would be best, to avoid inlined functions and all that.
Comment 6 Vincent Untz 2010-03-08 14:53:04 UTC
Is this still valid? Do we need it for 2.30?
Comment 7 Bastien Nocera 2010-03-09 11:06:55 UTC
Created attachment 155630 [details] [review]
Ignore errors when setting the monitor size fails

Otherwise the front-end application might crash with BadMatch.
Comment 8 Bastien Nocera 2010-03-09 11:08:32 UTC
Still valid, but I think I got the author wrong.

The patch is still being applied to the Fedora 13 package of gnome-desktop.
Comment 9 Vincent Untz 2010-03-27 11:51:44 UTC
Federico: can you please review this ASAP?
Comment 10 Vincent Untz 2010-03-30 21:09:20 UTC
Got approvals from freeze break on irc.