Bug 623250

next problem, which follows:, I cannot generate a xorg.conf anymore, because sax2 is gone.

and "Xorg -configure" crashes.

a little more info on this topic:

there is following code in /etc/X11/xdm/Xsetup:


#
# Check if the machine is a laptop and configure
# external output if XRANDR 1.2 is available
# 
if xrandr | grep -q "^default connected" ; then
  echo "Driver not XRANDR 1.2 capable, ignoring DISPLAYMANAGER_RANDR_MODE_* settings"
else
  if $halporp --key system.formfactor --string laptop ; then
    mode_auto="$DISPLAYMANAGER_RANDR_MODE_auto"
  else
    mode_auto=""
  fi  
  for ext in VGA DVI-I DVI-D DVI-A Composite S-Video Component LFP Proprietary ; do
    var="DISPLAYMANAGER_RANDR_MODE_${ext//-/_}"
    line="${!var}"
    test "x$line" = xauto && line="$mode_auto"
    mode="${line%% *}" 
    case "x$line" in
    x)  ;;  
    x*\ *)
      echo "xrandr for $ext: new mode $line"
      xrandr --newmode $line
      xrandr --addmode $ext $mode
      xrandr --output $ext --mode $mode
      ;;  
    x*) 
      echo "xrandr for $ext: known mode $line"
      xrandr --output $ext --mode $mode
      ;;  
    esac
  done
fi


This code cannot work for my laptop because my outputs are named "DVI1" and "LVDS1". So the settings from yast-systemconfig for randr-defaults have no effect.

I have now found a workaround (only for me), I pasted the following code into Xsetup (switch internal screen off, when external connected):


EXTERNAL_OUTPUT="DVI1"
INTERNAL_OUTPUT="LVDS1"

xrandr |grep $EXTERNAL_OUTPUT | grep " connected "
if [ $? -eq 0 ]; then
    xrandr --output $INTERNAL_OUTPUT --off --output $EXTERNAL_OUTPUT --auto
$EXTERNAL_OUTPUT --auto $EXTERNAL_LOCATION) &
else
    xrandr --output $INTERNAL_OUTPUT --auto
fi


now the kdm background is too small, but that does not hurt too much.

Is anyone working on this? I face the same bug here on OpenSuse 11.3, the
external monitor is always at 1024x768 after startup. 

My outputs are also named VGA1 and LVDS1, so I guess the problem identified
in comment #2 is at work here too.

What is sad is that the kernel mode setting gets the resolutions
correctly during boot, but those resolutions are apparently later ignored by 
the xserver, as it seems from the script of comment #2 that xrandr has to
be run at some point.

Wouldn't it be more natural if the server reads the resolutions reported by
the kernel and use those instead of getting them again through xrandr?

Following the hint from comment #2 I made the following patch which fixed the
issue for me. 

Instead of relying in the list of predefined outputs (which got my VGA1 wrong!)
the patch makes the list be based on what is actually reported by xrandr, and
runs xrandr on them selecting their preferred modes.

So it completely ignores the DISPLAYMANAGER_RANDR_MODE_* stuff and I think
it simplified the script a bit :-)

I will also attach the patch in the bugzilla.

--- /etc/X11/xdm/Xsetup	2010-03-17 11:59:56.000000000 +0100
+++ xsetup.sh	2010-08-23 19:22:30.019510398 +0200
@@ -76,29 +76,9 @@
 if xrandr | grep -q "^default connected" ; then
   echo "Driver not XRANDR 1.2 capable, ignoring DISPLAYMANAGER_RANDR_MODE_* settings"
 else
-  if $halporp --key system.formfactor --string laptop ; then
-    mode_auto="$DISPLAYMANAGER_RANDR_MODE_auto"
-  else
-    mode_auto=""
-  fi
-  for ext in VGA DVI-I DVI-D DVI-A Composite S-Video Component LFP Proprietary ; do
-    var="DISPLAYMANAGER_RANDR_MODE_${ext//-/_}"
-    line="${!var}"
-    test "x$line" = xauto && line="$mode_auto"
-    mode="${line%% *}"
-    case "x$line" in
-    x)	;;
-    x*\ *)
-      echo "xrandr for $ext: new mode $line"
-      xrandr --newmode $line
-      xrandr --addmode $ext $mode
-      xrandr --output $ext --mode $mode
-      ;;
-    x*)
-      echo "xrandr for $ext: known mode $line"
-      xrandr --output $ext --mode $mode
-      ;;
-    esac
+  for ext in `xrandr|grep " connected"| awk {'print $1'}` ; do
+	xrandr --output $ext --preferred
   done
 fi

Created attachment 384853 [details]
Patch to fix the wrong external resolutions on startup

Well, the code is obsolete and should be removed completely - together with the variables in /etc/sysconfig/displaymanager.

(In reply to comment #6)
> Well, the code is obsolete and should be removed completely - together with the
> variables in /etc/sysconfig/displaymanager.

Fixed for X11:Xorg/xorg-x11. Submitrequested for openSUSE:Factory/xorg-x11.

But if I simply delete those lines from the script, the resolution I get both
for the laptop and external monitor are 1024x768, even though the kernel got
them right during boot (the boot messages appear both at the laptop and external
monitor at their correct resolutions).

So where else are those resolutions changed when the display manager (wdm in my
case) start?

That's an Xserver default to chose the biggest available resolution for *both* monitors in clone mode, i.e. *same* resolution. IMHO it makes sense.

Discussion about that behaviour you can find in Bug #537488.

Thanks for taking the time, I really appreaciate it because now I have
more information too about what causes this.

But IMHO the Xserver default does not make sense. I would rather have
something like the patch by David Reveman in comment 2 from bug #537488

The intersection of the resolutions from both monitors will rarely be
useful, at least for me and I guess for others too.

My laptop has 1280x800 and I use two different external monitors,
one at my home with 1680x1050 and the other at the institute with
1920x1200. And for _both_ the Xserver default is useless and it makes
no sense.

I guess people always want the best of what the monitor has to offer,
and the desktop has to be adjusted to fit, not the reverse (I use wmaker,
so no krandr stuff etc).

In my case I simply use the external monitors and turn off the laptop screen.

Suppose also a beamer presentation in some conference. If you boot your laptop
with the cable to the beamer connected, you want it to display correctly 
at the conference room screen, using whatever native resolution the beamer
uses. Then your desktop or window manager has to be clever enough to do the
right thing.

I even wrote a patch for wmaker to deal with some part of this issue I have,
see here:

http://repo.or.cz/w/wmaker-crm.git/commit/c201e1612c1798106ccc2f806669a90b0bbb7a19

So is there no hope for me to get the resolutions correct in a flicker-free
boot process? The kernel got it right already, that's what disturbs me.
When xorg loads it screws up the resolutions which the kernel thought were
good, and I thought the point with the kernel mode setting was to avoid
this resolution changes from boot.

So I am sorry to write all this, but as things stand now they don't look
like they make sense. I fear that I will have to patch the xserver myself
and use it instead, but that is painful and it will go away once I move to
opensuse 11.4 etc.

(In reply to comment #10)
> But IMHO the Xserver default does not make sense. I would rather have
> something like the patch by David Reveman in comment 2 from bug #537488
>
> The intersection of the resolutions from both monitors will rarely be
> useful, at least for me and I guess for others too.

I agree that it makes sense to have such a patch for netbooks where the intersection of the resolutions ends up with 640x480. Otherwise I do *not*
agree.

> My laptop has 1280x800 and I use two different external monitors,
> one at my home with 1680x1050 and the other at the institute with
> 1920x1200. And for _both_ the Xserver default is useless and it makes
> no sense.

Hey, it's just the login screen (xdm, gdm, kdm), which shows this resolution.
Imagine the external 1920x1200 monitor is turned off, but still connected (you forgot about that or even don't know that). The displaymanager will likely optimize everything for the big external screen and you can't reach any longer the gdm panel or even user/password text field. We had such bug reports in the
past. No kidding! We really need a safe setup to avoid such situations.

> I guess people always want the best of what the monitor has to offer,
> and the desktop has to be adjusted to fit, not the reverse (I use wmaker,
> so no krandr stuff etc).

The desktop needs to take care about your preferences by using the previous
RANDR setup or if a change in monitor setup has been detected a safe setting. We do support KDE and Gnome as desktops. Use xrandr, if you prefer an unsupported WM.

> In my case I simply use the external monitors and turn off the laptop screen.

Easy to manage with xrandr during login.

> Suppose also a beamer presentation in some conference. If you boot your laptop
> with the cable to the beamer connected, you want it to display correctly 
> at the conference room screen, using whatever native resolution the beamer
> uses. Then your desktop or window manager has to be clever enough to do the
> right thing.

Especially with beamers it makes sense to use the same resolution, in most
cases this is 1024x768 anyway.

> So is there no hope for me to get the resolutions correct in a flicker-free
> boot process? The kernel got it right already, that's what disturbs me.
> When xorg loads it screws up the resolutions which the kernel thought were
> good, and I thought the point with the kernel mode setting was to avoid
> this resolution changes from boot.

Good point, but not everybody is using more than one monitor with different resolutions.

> So I am sorry to write all this, but as things stand now they don't look
> like they make sense. I fear that I will have to patch the xserver myself
> and use it instead, but that is painful and it will go away once I move to
> opensuse 11.4 etc.

Your decision of course, which we need to accept. We try the best to make most users happy, which obviously doesn't work out for everybody. That's the way it is.

Also I'm not sure why you're discussing this now in this bugreport. IMHO it belongs to Bug #537488.

(In reply to comment #11)
> (In reply to comment #10)
> > My laptop has 1280x800 and I use two different external monitors,
> > one at my home with 1680x1050 and the other at the institute with
> > 1920x1200. And for _both_ the Xserver default is useless and it makes
> > no sense.
> 
> Hey, it's just the login screen (xdm, gdm, kdm), which shows this resolution.
> Imagine the external 1920x1200 monitor is turned off, but still connected (you
> forgot about that or even don't know that). The displaymanager will likely
> optimize everything for the big external screen and you can't reach any longer
> the gdm panel or even user/password text field. We had such bug reports in the
> past. No kidding! We really need a safe setup to avoid such situations.

You are right. I hadn't thought about that, sorry.

But that also points out a deficiency in xorg, IHMO. Why can't we have
_both_ screens showing the same things at their native resolutions?
That's what the kernel seems to do while booting.

I don't know the details, but from my observation it seems there is
a huge opportunity to improvement here.
 
> > So is there no hope for me to get the resolutions correct in a flicker-free
> > boot process? The kernel got it right already, that's what disturbs me.
> > When xorg loads it screws up the resolutions which the kernel thought were
> > good, and I thought the point with the kernel mode setting was to avoid
> > this resolution changes from boot.
> 
> Good point, but not everybody is using more than one monitor with different
> resolutions.

Yeah, so I can wait till that becomes the standard or if some xorg
hacker has the same problem :-)

But from my user standpoint the kernel does a much better job than xorg
now. During boot I get both screens working nicely together, each one
at their native resolution.

So I wonder why xorg can't do that too. In the above case you mention,
there would be no problem because the laptop screen would be working
with native resolution too. 
 
> > So I am sorry to write all this, but as things stand now they don't look
> > like they make sense. I fear that I will have to patch the xserver myself
> > and use it instead, but that is painful and it will go away once I move to
> > opensuse 11.4 etc.
> 
> Your decision of course, which we need to accept. We try the best to make most
> users happy, which obviously doesn't work out for everybody. That's the way it
> is.

Ok, thanks a lot. I felt out of the "most users" set, but hey, that's OK
too. I will use my freedom to modify the sources etc once I have the time.
I was simply hoping that this bug could be solved by other means.
 
> Also I'm not sure why you're discussing this now in this bugreport. IMHO it
> belongs to Bug #537488.

Heh, right. But here is the bug where the conversation is, and I don't
know how to reply to your present comment and make it appear in the
other bug report.

But I want to thank you. You made it possible for me to try 
to find my own best solution. That's what I like about open source
to begin with! So all is fine, really.

> But that also points out a deficiency in xorg, IHMO. Why can't we have
> _both_ screens showing the same things at their native resolutions?
> That's what the kernel seems to do while booting.

You could do this by enable scaling on the smaller screen (xrandr --scale option),
but this looks rather awful.

> But from my user standpoint the kernel does a much better job than xorg
> now. During boot I get both screens working nicely together, each one
> at their native resolution.

It shows nothing more than a static splashscreen.

(In reply to comment #13)
> > But that also points out a deficiency in xorg, IHMO. Why can't we have
> > _both_ screens showing the same things at their native resolutions?
> > That's what the kernel seems to do while booting.
> 
> You could do this by enable scaling on the smaller screen (xrandr --scale
> option), but this looks rather awful.

Or panning as proposed in https://bugzilla.novell.com/show_bug.cgi?id=537488#c5.

(In reply to comment #13)
> > But that also points out a deficiency in xorg, IHMO. Why can't we have
> > _both_ screens showing the same things at their native resolutions?
> > That's what the kernel seems to do while booting.
> 
> You could do this by enable scaling on the smaller screen (xrandr --scale
> option),
> but this looks rather awful.

But then it's different. It's never awful to use a monitor/flat panel
at their _native_ resolution.

I would like to see things with 1280x800 on the laptop and 1920x1200 on the
monitor. 
 
> > But from my user standpoint the kernel does a much better job than xorg
> > now. During boot I get both screens working nicely together, each one
> > at their native resolution.
> 
> It shows nothing more than a static splashscreen.

No, I removed the splashscreen to see the boot messages both from the
kernel and from the init scripts. 

After seeing that it's possible to do this (native res. for both screens
at the same time), no other solution seems as good for me. After KMS my
expectations are quite high on this front :-)

I don't know how to code xorg to do what the kernel does, but from what
I see everyday in the morning from the kernel side when I boot, it should
be possible.

Or perhaps I am completely wrong, I don't want to complain to people who
actually code things up.

> I would like to see things with 1280x800 on the laptop and 1920x1200 on the
> monitor. 

Then I guess you would like panning. Unfortunately this is something most people don't understand (would again generate bugreports). I believe all reasonable options are already mentioned in this comment

  https://bugzilla.novell.com/show_bug.cgi?id=537488#add_comment

I'm getting tired discussing this again and again.