xscreensaver help

Dear Lazyweb,

I could use some Linux xscreensaver debugging help. I made some fairly large changes to make it cope with the brave new RANDR world where monitors can be hot-swapped and have their resolution changed willy-nilly. Please apply this patch and test some things for me, k? Launch xscreensaver with -verbose to see what it's actually up to.

"Bad" would be 1) crashing, 2) part of your desktop ever being incompletely blacked out by a screen saver, 3) running savers on video outputs that don't actually have monitors attached to them.

If you have (or can has) more than one monitor:

  • Do they all go blank when xscreensaver activates?
  • Do things look right if you add a monitor while the screen is blanked? While it is non-blanked?
  • Likewise when changing the resolution of the monitors using the "xrandr" command.
  • Does it correctly realize which monitors are actually attached to the system and in use?
  • Try configuring your machine to use the old-style multi-screen mode (where you have displays :0.0 and :0.1, and no Xinerama or RANDR.) Does it still behave sanely?
  • Can you configure your X server to use just the Xinerama extension and not the RANDR extension? Try that too.

If you have only one monitor, you can still test this. Use Ctrl-Alt-KeypadPlus and Ctrl-Alt-KeypadMinus to change the resolution of your monitor without changing the resolution of your desktop, so that bumping the mouse against the edge of the screen pans across your desktop. (You might need to turn off the Xinerama and RANDR extensions to make this work, I'm not sure.)

  • When xscreensaver launches, the savers should always be the size of the monitor (you shouldn't be seeing a zoomed-in portion of the saver, you should be seeing the whole thing.)
  • Lock the screen. While the screen is locked, zoom in and out. The xscreensaver window should stay the size of the visible portion of the screen.
  • With the screen locked, bump the mouse against the edge of the screen. The screen should remain covered.

Please let me know how that goes...

Update: There's a new patch with a few fixes. Please try that instead!

Tags: , , , ,
Current Music: jwz mixtape 00

19 Responses:

  1. BTW, is my pseudo (sudo?)-brick working out?

    • jwz says:

      It is, thanks a lot! It was very helpful.

      It's weird, though: when I plug in an external LCD, it never displays on it. The software believes the monitor is there, but the monitor never displays anything. That was close enough for me to debug this stuff, though.

  2. gen_witt says:

    I don't have multiple screens but I do have one that can rotate. Unfortunately it doesn't work, it continues to pop up a 1920x1200 window even though the root is 1200x1920.

    X.org 6.9.0, NVIDIA binary driver 100.14.11.

    For what it's worth xdpyinfo reports the screen as 1200x1920+0+0 when it's rotated. From the log looks like xscreensaver is recieving the RANDR events.

    Here is a log of me starting xscreensaver in landscape, activating the screensaver, unblanking the screen, rotating the monitor , activating the screensaver (which is now not covering my root window), unblanking the screen, and returning the monitor to its original rotation.


    • jwz says:

      What is the actual geometry of your root window in both states? "xwininfo -root".

      Can you build and run xscreensaver/driver/test-randr and tell me what it says when you rotate?


        • jwz says:

          Does this do it?

          diff -u -r1.5 screens.c
          --- screens.c 5 Jul 2008 12:55:38 -0000 1.5
          +++ screens.c 7 Jul 2008 01:22:42 -0000
          @@ -362,8 +362,17 @@

          size = XRRConfigCurrentConfiguration (rrc, &rot);
          rrsizes = XRRConfigSizes (rrc, &nsizes);
          - m->width = rrsizes[i].width;
          - m->height = rrsizes[i].height;
          + if (rot & (RR_Rotate_90|RR_Rotate_270))
          + {
          + m->width = rrsizes[i].height;
          + m->height = rrsizes[i].width;
          + }
          + else
          + {
          + m->width = rrsizes[i].width;
          + m->height = rrsizes[i].height;
          + }

          /* don't free 'rrsizes' */
          XRRFreeScreenConfigInfo (rrc);
          @@ -389,8 +398,18 @@
          m->desc = (rroi->name ? strdup (rroi->name) : 0);
          m->x = crtci->x;
          m->y = crtci->y;
          - m->width = crtci->width;
          - m->height = crtci->height;
          + if (crtci->rotation & (RR_Rotate_90|RR_Rotate_270))
          + {
          + m->width = crtci->height;
          + m->height = crtci->width;
          + }
          + else
          + {
          + m->width = crtci->width;
          + m->height = crtci->height;
          + }

          if (rroi->connection == RR_Disconnected)

          • gen_witt says:

            That makes it work with both 90 and 270 orientations. If I rotate the monitor while the screensaver is active, the active screensaver doesn't resize, but the blanker does keep my whole desktop blanked. When the next screensaver in the rotation starts it's the right size.

            • gen_witt says:

              It looks like it tried to resize the current screensaver, I wonder why it didn't work. Perhaps it tried to resize before the root geometry had changed, I don't really know how RANDR works.

              xscreensaver: 21:17:49: new layout:
              xscreensaver: 21:17:49: screens in use: 1
              xscreensaver: 21:17:49: 0/0: 1200x1920+0+0
              xscreensaver: 21:17:49: 0: resize 0x140001a from 1920x1200+0+0 to 1200x1920+0+0

              • jwz says:

                I think that what might be going on is that the window is resizing, but the running hack doesn't always get a ConfigureNotify event (and I have no idea how that's possible, but OverrideRedirect windows are mysterious).

                If the window was not resizing, then part of your desktop would still be visible.

                I assumed that I don't have to do anything special for the 180 case, right?

                I'm kinda curious how this would all work with RANDR 1.2 (you have 1.1) and multiple screens. Do I need to adjust X and Y when the screen is rotated, as well as W and H? I can't even guess.

                • gen_witt says:

                  I get a black rectangle in the missing spot. But when I run the screensaver windowed it does resize correctly. I assume it's not overideredirect when it's windowed because it gets decorated by my window manager.

  3. jsbowden says:

    Is this strictly a Linux thing, or would you be interested in results from FreeBSD as well?

  4. base3 says:

    When I resize using Ctrl+Alt+NumMinus, the screensaver is bigger than the size of the screen, and I can move it around by pushing the mouse against the edge of the screen exactly the same as the desktop.
    xorg 7.1.0 + via driver

    I tested this before building the new patched code, using xscreensaver-5.04, and the demo was normal size, but bumping against the screen edge moved the screensaver to show the desktop 'behind' it. hth.

    • base3 says:

      Sorry, I meant to also say that the behaviour (using the new code with the second patch you posted) is the same whether you start xscreensaver before or after resizing.

    • jwz says:

      Can you describe in more detail what you're seeing?

      I think that it should be doing this:

      1. desktop is 1024x768
      2. viewport (monitor resolution) is 800x600
      3. lock screen, with mouse near edge of screen
      4. move mouse fast/hard
      5. screen scrolls slightly, because that motion hit the edge
      6. passwd/unlock dialog box appears
      7. screen is immediately scrolled back to where it was before (undo_vp_motion in lock.c)
      8. mouse is grabbed within the rectangle of that dialog box, and from now on, you can't even get the mouse toward the screen edge to scroll.
      9. KP+ / KP- don't do anything (xfree_lock_mode_switch in lock.c)
      10. unlock screen
      11. KP+ / KP- work again

      Which part of that does not match your experience?

      • base3 says:

        I must be very dense today, because I can't get the screen to lock, although the screensaver runs fine. So I haven't been able to test the above.

        However, this is what I am experiencing without locking the screen
        * Desktop is 1024x768
        * I resize the viewport so that it is 800x600. I am now seeing the bottom right 'corner' of my desktop, enlarged to fit on the whole screen
        * Without scrolling the viewport, I start the screensaver
        * The julia hack starts, I see the bottom right 'corner' of julia, again zoomed in. The pixels are interpolated so it looks a little strange.
        * I jog the mouse fast towards the top of the screen. The viewport scrolls so that the top part of the julia hack appears briefly, before the screensaver exits and the desktop reappears.

        I'll check what I am doing wrong with the screen lock and try and follow the above instructions again.

        • jwz says:

          Thanks, also please mail me the complete "xscreensaver -verbose" log of the run, both with and without locking. It sounds like it's not realizing that there's a VP at all, maybe. (Also mail me the output of "configure").

          • base3 says:

            I managed to get the screen to lock and tried what you suggested. With the viewport resized, I run 'xscreensaver-command lock', when the mouse cursor is near an edge of the screen I can scroll towards. The hack starts, as before a zoomed-in portion fills the whole screen. When I jog the mouse fast to scroll, xscreensaver exits.

            xscreensaver: 02:57:19: 0: suspending pid 18240 (julia)
            xscreensaver: 02:57:19: non-PAM password auth.
            xscreensaver: 02:57:19: 0: mouse is at 1023,0.
            xscreensaver: 02:57:19: 0: creating password dialog ("")
            xscreensaver: 02:57:19: grabbing server...
            xscreensaver: 02:57:19: 0: ungrabbing mouse (was 0x47).
            xscreensaver: 02:57:19: 0: grabbing mouse on 0x4600031... GrabSuccess.
            xscreensaver: 02:57:19: ungrabbing server.
            xscreensaver: 02:57:19: 0: child pid 18240 (julia) stopped with signal 19.
            xscreensaver: 02:57:19: 0: vp moved to (384,0); moved it back to (0,288).


            xscreensaver: 02:57:19: X Error! PLEASE REPORT THIS BUG.
            xscreensaver: 02:57:19: screen 0/0: 0x47, 0x0, 0x4600022


            X Error of failed request: BadValue (integer parameter out of range for operation)
            Major opcode of failed request: 135 (XFree86-VidModeExtension)
            Minor opcode of failed request: 11 (XF86VidModeGetViewPort)
            Value in failed request: 0x4600031
            Serial number of failed request: 10600
            Current serial number in output stream: 10600

            xscreensaver: 02:57:19: 0: killing pid 18240 (julia)
            xscreensaver: 02:57:19: dumping core (because of synchronous X Error)

            I also tested locking the screen and moving the mouse to unlock it, but not far enough to scroll. The password box appears. I can still scroll the screen now, but only while keeping the mouse inside the password box. (The password box overlaps one corner of the screen since we are still 'zoomed in'. I can move towards that corner to scroll in that direction.)

            I am mailing you several logs and 'configure' output.

            The reason I couldn't lock the screen earlier is because either xscreensaver/configure thought PAM was installed and it isn't, or because PAM is installed but doesn't work. Rather than figure this out I built xscreensaver w/o PAM just by manually editing a line in configure:

            --- configure~ 2008-07-07 22:11:04.000000000 +0000
            +++ configure 2008-07-09 02:40:37.000000000 +0000
            @@ -12865,7 +12865,7 @@
            # Default to building PAM support on all other systems, if it exists.
            - with_pam_default=yes
            + with_pam_default=no

            I assume this didn't make a difference, but just in case.