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

(Reply) (Thread)

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.

(Reply) (Parent) (Thread)

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.

http://www.firebomb-w3c.org/xscreensaver-randr-log.txt

(Reply) (Thread)

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?

Thanks!

(Reply) (Parent) (Thread)

An answer in script form,

http://www.firebomb-w3c.org/xscreensaver-randr-script.txt

(Reply) (Parent) (Thread)

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;
+                }
+
               j++;
 
               if (rroi->connection == RR_Disconnected)

(Reply) (Parent) (Thread)

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.

(Reply) (Parent) (Thread)

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

(Reply) (Parent) (Thread)

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.

(Reply) (Parent) (Thread)

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.

(Reply) (Parent) (Thread)

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

(Reply) (Thread)

Interested in results on any X11 system.

(Reply) (Parent) (Thread)

When I get into work tomorrow and I get caught up, I'll grab a spare monitor, update xscreensaver, and see what happens for you then.

(Reply) (Parent) (Thread)

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.

(Reply) (Thread)

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.

(Reply) (Parent) (Thread)

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?

(Reply) (Parent) (Thread)

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.

(Reply) (Parent) (Thread)

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").

(Reply) (Parent) (Thread)

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
;;
esac

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

(Reply) (Parent) (Thread)