Bug 270236

Summary: Different xorg.conf is installed then was created during installation
Product: [openSUSE] openSUSE 10.3 Reporter: Volker Kuhlmann <bugz57>
Component: SaX2Assignee: Marcus Schaefer <ms>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None    
Version: Alpha 3   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Whiteboard:
Found By: Other Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Volker Kuhlmann 2007-05-01 08:38:47 UTC
During system installation yast's peripherals(?) config suggests some sensible value for screen number of pixels, refresh rate, bit depth. I changed 2 of those numbers in yast, then checked it when that question was asked. sax2 starts up in proof mode, video timings can be changed etc. All is fine.

Dunno how I returned to yast, but I didn't click cancel if there was such a thing. There might have been an "ok" button, or the usual "save" button.
autoyast.xml, saved at the end of install, contains the settings I wanted.

When the X server first starts to run kdm, the monitor timing is way out. This was supposed to be already adjusted before! Why did this not get saved properly?

This may be relevant: the monitor is a very old CRT without DDI.
System yast logs are here:
https://bugzilla.novell.com/attachment.cgi?id=136741
Comment 1 Marcus Schaefer 2007-05-01 09:17:36 UTC
Did you check the contents of /etc/X11/xorg.conf whether you can
find your values in there or not ?

Thanks
Comment 2 Volker Kuhlmann 2007-05-01 10:32:13 UTC
I copied xorg.conf before I ran sax2 again to fix things up. Differences are:

-  DisplaySize  345 259
+  DisplaySize  305 229

-  Modeline     "1024x768" 75.00 1024 1048 1184 1328 768 771 777 806
+  Modeline     "1024x768" 76.16 1024 1088 1200 1360 768 785 788 840
+  Modeline     "800x600" 45.50 800 840 920 1040 600 601 604 625

-    Modes      "1024x768"
+    Modes      "1024x768" "800x600"
[several times]

+  Screen       0

The pixel number was there, but the timing was wrong. I had increased vertical from 60 to 70Hz, the 70 was in the monitor model name identifier. (sax2 the 2nd time also added all the 800x600 settings, but that's not part of the problem. The DisplaySize change resulted from a screen diagonal adjustment; I usually have to set about 14.1-15 inch for this 17 inch CRT to get usable application font sizes. It defaulted to about 20 though - without DDI any default will of course be wrong.)
Comment 3 Marcus Schaefer 2007-05-02 08:51:10 UTC
I don't understand why the timing should be wrong. You increased it from
60 to 70 Hz and the calculated modeline:

    Modeline "1024x768" 76.16 1024 1088 1200 1360 768 785 788 840

is at 
  
   56.00 Khz
   66.67 Hz

* so this is a correct in range modeline. The 800x600 is added by default
  but doesn't matter here, ok

* the display size is adapted according to the information from DDC
  (hwinfo --monitor ?) or it is a best guess concerning the selected
  resolution which I know is always wrong ;) but better than the default

Hmmm, ? sorry don't get it
Comment 4 Volker Kuhlmann 2007-05-05 00:09:33 UTC
During installation, yast allows to set the basic settings screen size in pixels, V refresh, bit depth. I probably changed pixels and V refresh, then when the sax2 question popped up, I clicked "yes, test this now". The test screen was perfect, so I exited without making timing changes.

When kdm started, the visible area was way off to the bottom right of the screen, and may have had the wrong size too.

This bug report is for the bug of not getting after installation what was set and tested(!) during installation.
Comment 5 Marcus Schaefer 2007-05-07 08:44:07 UTC
sounds pretty strange to me. Could you try to reproduce that
with the following commands:

   init 3
   sax2 -r
   ---> click on change configuration
   ---> perform the same changes as you did while installing. Please
        note the yast proposal and the sax2 GUI are using the same
        library (libsax) to do the job so the result is the same
   ---> click on OK
   ---> click on Test

   ---> How does the test look like ?
   ---> Save the Test and exit sax

   ---> start X by calling

        X

   ---> the result should be the same as in the test
        spoken about geometry and resolution

Thanks
Comment 6 Marcus Schaefer 2007-05-11 10:30:37 UTC
no further information... closed
Comment 7 Volker Kuhlmann 2007-05-14 08:53:25 UTC
Sorry, one thing at a time.

Thanks for your suggestions, tried them but can't reproduce. The initial suggestion doesn't quite fit and is @60Hz, so I changed to @70Hz and made timing adjustments in the following tests. They're all saved correctly and X and init 5 showed the same picture.

Repeated the exercise without making changes to the suggestion by sax2 -r, again the picture after init 5 is the same as the suggestion.

Both times with xorg.conf deleted and init 3 before starting sax2.

Thanks for looking at it, something went wrong but dunno what. I'll have another go at it with alpha4.
Comment 8 Volker Kuhlmann 2007-05-27 12:52:23 UTC
10.3a4, same problem:
Offered by yast (not sax2!) during installation is 1024x768@60Hz, aspect unconfigured.
I change this by clicking on the underlined word to 1024x768@70Hz, and aspect from 21" 4/3 to 15.4" 4/3.

I click on "test this config". The visible area is nicely centred on the monitor glass. I click save config (this is sax2). The installers comes back on screen, with whatever graphics setup it uses.

Later when switching to runlevel 5, X11 restarts with the new config, the visible area is off the screen.

I forgot to save the X11 config saved by yast respectivcely whatever program yast starts during installation. Now there's only xorg.conf-install (presumably used by the installer) and xorg.conf, plus a saxsave of it with the same context.

Without any doubt the test initiated by yast during installation uses a different xorg.conf, or anyway a different X server setting, then the xorg.conf written by yast after the test!

Reopening.
Comment 9 Marcus Schaefer 2007-06-03 19:32:19 UTC

*** This bug has been marked as a duplicate of bug 264646 ***