BFe: No signal with Samsung SyncMaster 570s and ProSavage8 [patch]

Hi peterbe,

Thanks for including the attached files. Could you also include your /var/log/Xorg.0.log?

That would be from hardy, since I can't boot intrepid and get at a shell.

On Fri, Nov 7, 2008 at 1:26 AM, Bryce Harrington
<email address hidden> wrote:
> Hi peterbe,
>
>
> Thanks for including the attached files. Could you also include your /var/log/Xorg.0.log?
>
>
> ** Changed in: xserver-xorg-video-savage (Ubuntu)
> Status: New => Incomplete
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Here is the /var/log/Xorg.0.log

In this case, I went through the motions of an actual install, rather than a live boot. The boot failed, without installing anything, but ended up in a shell, so that I could copy the log file to the hard disk.

A quick glance at the file tells me there is useful information here about the failure to find an appropriate screen mode.

Here is the /var/log/Xorg.0.log from booting Feisty 7.04. The display was initialized properly in 1024x768 resolution, the maximum supported byt the Samsung display.

Here is the xorg.conf file generated by booting feisty as a live CD. This file may be used to solve resolution problems under Hardy as well.

Here is an Xorg.0.log file generated from installing hardy on the same system, using the alternate CD.

An attempt to boot from the live CD (desktop CD) failed. I wasn't able to save the log file from that failed attempt.

xorg.conf file from alternate install of hardy 8.04.1

The maximum screen resolution with this file was 800x600.

I was able to get 1024x768 resolution by replacing this with the xorg.conf from Feisty 7.04 (see above).

This is marked as 'incomplete'. What is needed?

Peter send the xorg.conf generated at 7.04 via attach mail, when boot at 800 x 600 download the xorg.conf and overwrite this in 8.10, This impossible?

I sent the 8.04 Feisty xorg.conf and Xorg.0.log files on 2008-11-08 - see above.

I can send hardy 8.04 files if that will help - that's a case where I had to overwrite the xorg.conf with the Feisty version.

I'll see what I can do regarding 8.10 files. I didn't get very far into the live boot or install on this system.

I also have the xorg.conf and Xorg.0.log files from Hardy 8.04.1 attached above.

I'll make another attempt to get the files from the failed attempts to boot or to start installing 8.10.

I finally succeeded in getting a log file from an attempt to boot the 8.10 disk. Also I was able to get the screen to start in a 1024x768 mode.

I was able to get into a console after identification of the display failed. At that point, I was able to save the Xorg.0.log file, as before. it is already attached nearer the top of this report, showing a failure to identify the screen hardware.

At that point xorg.conf was empty. I was then able to copy in the 7.04 xorg.conf file and run 'startx' to start the screen.

Eventually the screen initialized at 1024x768 resolution, and the usual top and bottom panels and default screen background appeared. From the log file:

(--) SAVAGE(0): Chose mode 117 at 60Hz.
(II) SAVAGE(0): virtualX:1024,virtualY:768

I have attached the Xorg.0.log file from after the screen started.

This certainly looks wrong in your original log file:
(II) SAVAGE(0): Configured Monitor: Using hsync value of 0.00 kHz
(II) SAVAGE(0): Configured Monitor: Using vrefresh value of 0.00 Hz

It would be nice if you could test Jaunty and provide an Xorg.0.log. Unfortunately there are reports that the current savage driver in Jaunty is broken, but you can try a patched version from my PPA https://launchpad.net/~tormodvolden/+archive

If you test a Jaunty live CD, I suggest you boot in "failsafe graphics" mode (vesa driver) and then installs the patched driver, then change xorg.conf to use savage and restart X (log out and in again). If you now get a black screen, it should be possible to switch to a console with ctrl-alt-F1, log in and copy the Xorg.0.log, switch to vesa again in xorg.conf and restart X again with "sudo /etc/init.d/gdm restart".

Please also add
 Option "ModeDebug" "true"
to the Device section of your xorg.conf.

So I should download the normal Jaunty live CD, boot in failsafe vesa
mode, also have your downloaded driver on my HD. How do I install your
driver from where it is?

Peter

On Sun, Jan 11, 2009 at 3:28 PM, Tormod Volden <email address hidden> wrote:
> Please also add
> Option "ModeDebug" "true"
> to the Device section of your xorg.conf.
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I can't get the Jaunty CD to boot into X, even in 'safe' mode.

The Samsung Syncmaster display won't accept any of the modes the driver tries.

Peter

On Sun, Jan 11, 2009 at 12:04 PM, Tormod Volden
<email address hidden> wrote:
> This certainly looks wrong in your original log file:
> (II) SAVAGE(0): Configured Monitor: Using hsync value of 0.00 kHz
> (II) SAVAGE(0): Configured Monitor: Using vrefresh value of 0.00 Hz
>
> It would be nice if you could test Jaunty and provide an Xorg.0.log.
> Unfortunately there are reports that the current savage driver in Jaunty
> is broken, but you can try a patched version from my PPA
> https://launchpad.net/~tormodvolden/+archive
>
> If you test a Jaunty live CD, I suggest you boot in "failsafe graphics"
> mode (vesa driver) and then installs the patched driver, then change
> xorg.conf to use savage and restart X (log out and in again). If you now
> get a black screen, it should be possible to switch to a console with
> ctrl-alt-F1, log in and copy the Xorg.0.log, switch to vesa again in
> xorg.conf and restart X again with "sudo /etc/init.d/gdm restart".
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Is it not possible to switch to a console with ctrl-alt-F1?

I was hoping you could get X running with the vesa driver, and then install the patched driver from the internet. If you have it already downloaded on the hard drive, that's even better, especially in the case vesa won't work. As long as you can log in on the console, that is.

Then mount your hard drive with "sudo mount /dev/sda1 /mnt" (replace sda1 with the name of the right partition) and install the driver with "sudo dpkg -i /mnt/home/peter/Desktop/xserver-xorg-video-savage*" or whatever is the right path to the deb package.

I just tried again to boot the 9.04 'jaunty' CD - I was unable to get
a console with ctrl-alt-F1, trying several times before and after the
screen started displaying the little windows saying the current screen
mode. Apparently the driver is trying a number of modes, and doesn't
get feedback from the monitor that any mode does work.

Now this did come up with a useable mode in earlier versions of
Ubuntu. And also Windows XP does come up with a working mode - it
boots fine (this is a dual-boot system).

It would be really nice if the boot process would come up with a
manual selection of screen modes, including 800x600 and 1024x768
resolutions and maybe some other parameters, when mode selection fails
after a while.

I tried the Jaunty disk on an Averatec laptop (model 3280) that has
similar problems. After some time it came up with a menu which allowed
me to get into a shell in a small window - I didn't proceed further
since the existing OS was a recent Debian, not Ubuntu, so I didn't
have the right xorg.conf file to try.

Another approach would be to create a driver CD with the experimental
driver - apparently one can preinstall such a driver before actually
booting the OS CD. Also being able to configure xorg.conf manually
would be desirable.

Peter

On Mon, Jan 12, 2009 at 6:41 AM, Tormod Volden <email address hidden> wrote:
> Is it not possible to switch to a console with ctrl-alt-F1?
>
> I was hoping you could get X running with the vesa driver, and then
> install the patched driver from the internet. If you have it already
> downloaded on the hard drive, that's even better, especially in the case
> vesa won't work. As long as you can log in on the console, that is.
>
> Then mount your hard drive with "sudo mount /dev/sda1 /mnt" (replace
> sda1 with the name of the right partition) and install the driver with
> "sudo dpkg -i /mnt/home/peter/Desktop/xserver-xorg-video-savage*" or
> whatever is the right path to the deb package.
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

If you add "text" to the boot parameters (the kernel line, F6 in the CD boot menu), it will not start X. You can then log in on the console and install the driver like mentioned above. To start X an X session, type "startx".

I don't think the driver is trying out different modes, it's just the monitor trying to match the signal from the driver. In principle the X server will ask the monitor about which modes it accepts, and tell the driver to use the "best" mode (usually the highest resolution or the one the monitor designates as "preferred"). If we can get the modedebug Xorg.0.log, we can see the details of this communication.

But not being able to switch the console might indicate more issues than just a wrong mode. You see the usplash progress bar until X should start, right? Try also to remove the "splash" word in the boot parameters - sometimes usplash interferes with the console modes and corrupts the screen.

Oh, good. I was wondering whether there was a way to boot in text
mode. That will make it MUCH easier to proceed!

Also removing the splash progress bar might help, I'll see.

I'll be home in a couple of hours to try this! Then I can try either
the new driver, or my old xorg.conf file, or both. I expect to be able
to proceed Ok.

What the monitor appears to do during its attempts to work is to turn
on, display the warning box about mode incompatibility somewhere on
the screen, turn its 'on' LED off, and repeat the same thing at random
parts of the screen ... apparently forever in this case.

Thanks!

On Wed, Jan 14, 2009 at 3:49 PM, Tormod Volden <email address hidden> wrote:
> If you add "text" to the boot parameters (the kernel line, F6 in the CD
> boot menu), it will not start X. You can then log in on the console and
> install the driver like mentioned above. To start X an X session, type
> "startx".
>
> I don't think the driver is trying out different modes, it's just the
> monitor trying to match the signal from the driver. In principle the X
> server will ask the monitor about which modes it accepts, and tell the
> driver to use the "best" mode (usually the highest resolution or the one
> the monitor designates as "preferred"). If we can get the modedebug
> Xorg.0.log, we can see the details of this communication.
>
> But not being able to switch the console might indicate more issues than
> just a wrong mode. You see the usplash progress bar until X should
> start, right? Try also to remove the "splash" word in the boot
> parameters - sometimes usplash interferes with the console modes and
> corrupts the screen.
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I made some progress - I was able to boot into text mode after
modifying the boot parameters - adding 'text' and removing the
'splash', and specifying the vesa mode.

At this point, I was able copy files to this system from another, using scp.

I then copied the experimental driver and my old xorg.conf file to the
sytem, saved the initial xorg.conf to a backup, copied my xorg.conf
file to /etc/X11, and tried to install the driver. The install failed,
indicating that "xserver-xorg-core conficts with
xserver-xorg-video-4'. I'm not sure how to solve that problem!

Even though I knew the old driver wouldn't work, I tried running
startx. As expected, it failed, but I will provide the Xorg.0.log
file that resulted.

Peter

On Wed, Jan 14, 2009 at 3:49 PM, Tormod Volden <email address hidden> wrote:
> If you add "text" to the boot parameters (the kernel line, F6 in the CD
> boot menu), it will not start X. You can then log in on the console and
> install the driver like mentioned above. To start X an X session, type
> "startx".
>
> I don't think the driver is trying out different modes, it's just the
> monitor trying to match the signal from the driver. In principle the X
> server will ask the monitor about which modes it accepts, and tell the
> driver to use the "best" mode (usually the highest resolution or the one
> the monitor designates as "preferred"). If we can get the modedebug
> Xorg.0.log, we can see the details of this communication.
>
> But not being able to switch the console might indicate more issues than
> just a wrong mode. You see the usplash progress bar until X should
> start, right? Try also to remove the "splash" word in the boot
> parameters - sometimes usplash interferes with the console modes and
> corrupts the screen.
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Here is the log, trying to startx with the driver on the Jaunty alpha disk.

As I said above, I was unable to install the driver under development:

   xserver-xorg-video-savage_2.2.1+git20081117.aea0496f-0ubuntu0tormod_i386.deb

Thanks for the log. Well, you picked the wrong (Intrepid) version from the PPA, that's why you get the xserver-xorg-video-4 conflict.

You might also be able to avoid the crash by specifying:
 Option "DRI" "off"
in the Device section of your xorg.conf but with the fixed driver it shouldn't be needed.

Oops - I'll download the right driver and try again. Actually I'm not
sure what IS the right version..

On Thu, Jan 15, 2009 at 1:45 AM, Tormod Volden <email address hidden> wrote:
> Thanks for the log. Well, you picked the wrong (Intrepid) version from
> the PPA, that's why you get the xserver-xorg-video-4 conflict.
>
> You might also be able to avoid the crash by specifying:
> Option "DRI" "off"
> in the Device section of your xorg.conf but with the fixed driver it shouldn't be needed.
>
>
> ** Summary changed:
>
> - No signal with Samsung SyncMaster 750s and ProSavage8
> + crashes on startup - segfault in DRIFinishScreenInit
>
> ** Description changed:
>
> Binary package hint: xserver-xorg-video-savage
>
> This occurs on trying to boot the intrepid 8.10 CD as a live CD on a gBox computer
> Display controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]
> Display: Samsung SyncMaster 570S TFT
>
> While trying to boot the CD, eventually the display controller is unable
> to find a mode that works on the Samsung display. The Samsung display
> will indicate this by flashing small windows indicating that the
> controller output is incompatible with the display. I have found no way
> to get to a shell to attempt to fix the situation, e.g. by changing the
> xorg.conf file.
>
> Under hardy (actually installed), what happened is that a compatible
> 800x600 mode was found, and I could add an xorg.conf file which was
> generated by booting a 7.04 live CD, restart X, and get to the 1024x768
> mode supported by the display.
>
> Under intrepid, I was unable to get to the point where I could copy over
> the (possibly) 'good' xorg.conf.
>
> See bug # 212510, and some bugs listed as duplicates to that, for some
> further information - this bug report is specifically for this
> controller/display combination under intrepid; 212510 is listed as fixed
> for the original hardware combination, but is clearly not fixed for this
> hardware combination and others I mention in that report.
> +
> +
> + Backtrace:
> + 0: /usr/bin/X11/X(xorg_backtrace+0x3b) [0x813281b]
> + 1: /usr/bin/X11/X(xf86SigHandler+0x55) [0x80c5dc5]
> + 2: [0xb806d400]
> + 3: /usr/lib/xorg/modules/extensions//libdri.so(DRIFinishScreenInit+0xb1) [0xb8065821]
> + 4: /usr/lib/xorg/modules/drivers//savage_drv.so(SAVAGEDRIFinishScreenInit+0x60) [0xb7ae9dc0]
> + 5: /usr/lib/xorg/modules/drivers//savage_drv.so [0xb7add6f2]
> + 6: /usr/bin/X11/X(AddScreen+0x19d) [0x80711dd]
> + 7: /usr/bin/X11/X(InitOutput+0x206) [0x80adeb6]
> + 8: /usr/bin/X11/X(main+0x1e1) [0x80718d1]
> + 9: /lib/tls/i686/cmov/libc.so.6(__libc_start_main+0xe5) [0xb7c44775]
> + 10: /usr/bin/X11/X [0x8070f61]
> + Saw signal 11. Server aborting.
> + ddxSigGiveUp: Closing log
>
> ** Summary changed:
>
> - crashes on startup - segfault in DRIFinishScreenInit
> + No signal with Samsung SyncMaster 750s and ProSavage8
>
> ** Description changed:
>
> Binary package hint: xserver-xorg-video-savage
>
> This occurs on trying to boot the intrepid 8.10 CD as a live CD on a gBox computer
> Display controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]
> Display: Samsung SyncMaster 570S TFT
>
> While trying to boot the CD,...

I went back to trying the 8.10 Intrepid live CD - using 'text' and
eliminating 'splash' in the boot line enables it to boot in text mode,
then using the old xorg.conf from 7.04 enables X to start.

On Wed, Jan 14, 2009 at 3:49 PM, Tormod Volden <email address hidden> wrote:
> If you add "text" to the boot parameters (the kernel line, F6 in the CD
> boot menu), it will not start X. You can then log in on the console and
> install the driver like mentioned above. To start X an X session, type
> "startx".
>
> I don't think the driver is trying out different modes, it's just the
> monitor trying to match the signal from the driver. In principle the X
> server will ask the monitor about which modes it accepts, and tell the
> driver to use the "best" mode (usually the highest resolution or the one
> the monitor designates as "preferred"). If we can get the modedebug
> Xorg.0.log, we can see the details of this communication.
>
> But not being able to switch the console might indicate more issues than
> just a wrong mode. You see the usplash progress bar until X should
> start, right? Try also to remove the "splash" word in the boot
> parameters - sometimes usplash interferes with the console modes and
> corrupts the screen.
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

The right version for Jaunty would be xserver-xorg-video-savage - 1:2.2.1+git20081230.aea0496f-0ubuntu0tormod . On the PPA page there is a column called "Series" which tells which versions are for Jaunty. I am sorry if this was not clear.

The reason I am pestering you to get a ModeDebug log from Jaunty, is that we should report this upstream, and the first thing they ask for is that we test against a recent version, to avoid fixing things that already have been fixed. And I might take a closer look at the edid communication and mode selection code myself, but I would prefer to spend the time on as new code as possible...

Your latest result is the same as in comment 13, right? Thanks for your persistence, I hope you can give Jaunty another try :)

Thanks! I'll download that tonight or tomorrow, and try it. I suspect
it will work. And I'll post my results.

It's good this is going upstream - this problem affects not only
Ubuntu and Debian, but Fedora as well, when I've tried recent live
CDs. Probably several other distros, including Gentoo. I experience it
on my Averatec laptop as well as this gBox P4 computer.

On Thu, Jan 15, 2009 at 2:26 PM, Tormod Volden <email address hidden> wrote:
> The right version for Jaunty would be xserver-xorg-video-savage -
> 1:2.2.1+git20081230.aea0496f-0ubuntu0tormod . On the PPA page there is a
> column called "Series" which tells which versions are for Jaunty. I am
> sorry if this was not clear.
>
> The reason I am pestering you to get a ModeDebug log from Jaunty, is
> that we should report this upstream, and the first thing they ask for is
> that we test against a recent version, to avoid fixing things that
> already have been fixed. And I might take a closer look at the edid
> communication and mode selection code myself, but I would prefer to
> spend the time on as new code as possible...
>
> Your latest result is the same as in comment 13, right? Thanks for your
> persistence, I hope you can give Jaunty another try :)
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I can't find the file. Could you send me the exact URL for the page it's on?

On Thu, Jan 15, 2009 at 2:26 PM, Tormod Volden <email address hidden> wrote:
> The right version for Jaunty would be xserver-xorg-video-savage -
> 1:2.2.1+git20081230.aea0496f-0ubuntu0tormod . On the PPA page there is a
> column called "Series" which tells which versions are for Jaunty. I am
> sorry if this was not clear.
>
> The reason I am pestering you to get a ModeDebug log from Jaunty, is
> that we should report this upstream, and the first thing they ask for is
> that we test against a recent version, to avoid fixing things that
> already have been fixed. And I might take a closer look at the edid
> communication and mode selection code myself, but I would prefer to
> spend the time on as new code as possible...
>
> Your latest result is the same as in comment 13, right? Thanks for your
> persistence, I hope you can give Jaunty another try :)
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

The nearest file I find is

xserver-xorg-video-savage_2.2.1+git20081230.aea0496f-0ubuntu0tormod_i386.deb
 (96.6 KiB)

On Thu, Jan 15, 2009 at 2:26 PM, Tormod Volden <email address hidden> wrote:
> The right version for Jaunty would be xserver-xorg-video-savage -
> 1:2.2.1+git20081230.aea0496f-0ubuntu0tormod . On the PPA page there is a
> column called "Series" which tells which versions are for Jaunty. I am
> sorry if this was not clear.
>
> The reason I am pestering you to get a ModeDebug log from Jaunty, is
> that we should report this upstream, and the first thing they ask for is
> that we test against a recent version, to avoid fixing things that
> already have been fixed. And I might take a closer look at the edid
> communication and mode selection code myself, but I would prefer to
> spend the time on as new code as possible...
>
> Your latest result is the same as in comment 13, right? Thanks for your
> persistence, I hope you can give Jaunty another try :)
>
> --
> No signal with Samsung SyncMaster 750s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Yes, that is the right file.

With that driver, I was able to startx ok!

The only glitch was that the user-switcher applet wouldn't start (or kept stopping each time I clicked on the popup which announced that it was failing).

I'll attach the log file here.

Here is the latest xorg.conf that works with the 9.04 driver

The log file shows complaints about things like nonexistent fonts, nothing serious.

The real remaining issue, in my opinion, is whether the installer will recognize which driver to use, and set up the right screen mode, and when that will happen. There may still have to be a manual X configurator for when the automatic process fails.

That was the wrong xorg.conf file.

Here is the latest xorg.conf that works with the 9.04 driver

The log file shows complaints about things like nonexistent fonts, nothing serious.

The real remaining issue, in my opinion, is whether the installer will recognize which driver to use, and set up the right screen mode, and when that will happen. There may still have to be a manual X configurator for when the automatic process fails.

Great! But this is supposed to work out-of-the-box without any modified xorg.conf. Can you please try without any xorg.conf? It might be a challenge to fish out the log if the monitor goes off, but there are some ways:
On a virtual console (alt-F2 for instance, not the one where you run startx), mount your hard drive on /mnt, then run:
 sleep 60; cp /var/log/Xorg.0.log /mnt/var/tmp/ ; sync
Now you have 60 seconds to switch to the other screen (alt-F1) and run startx. Wait until the time has run out before rebooting. (Try the cp command without the sleep first just to make sure it can copy to the hard drive, before you set it up and run startx.)

BTW, the conf file in your last comment turned out to be the log instead...

Here's the xorg.conf file - we seem to have some problem getting the right files! :)

This Xorg.0.log file was generated as requested - with no xorg.conf file.

There was no crash - no screen was found, as the log file says, so console 1 stayed in text mode.

Putting in the old xorg.conf (as in the previous posting) allows X to start.

The EDID transfer (over DDC) fails so the driver can not retrieve the sync ranges from the monitor. I can imagine that Hardy used to supply some default sync ranges, which made it come up in 800x600. When you specify the wider ranges in xorg.conf, 1024x768 is found to be possible.

I am not sure if the driver should also try to get the edid via VBE. Or provide some conservative default ranges if everything else fails. From what I understand from the code it should provide default hsync range of 31.50-37.90 kHz. So maybe some false information is detected with range 0-0.

Can you please install the "read-edid" package, and from the text console, run
 sudo get-edid | parse-edid > edid.txt 2>&1
and attach edid.txt here?

BTW, Guido's bug 212510 was a bit different, because he had EDID transfer working.

You have two problems:
1) EDID can't be retrieved from the monitor. The monitor should be fine (since Guido has the same) but there is something specific to your prosavage card that fails.

2) In lack of probed sync ranges, the server should pick reasonable defaults. I have tested on my savage laptop by disabling DDC that the default 31.50-37.90 kHz is chosen. So in your case there must be a invalid value that keeps the default from being used. Please try the attached (Jaunty) package, it adds some extra debug output to the log.

I tried the new debug package containing a screen driver. It was able to start X , arriving at a screen resolution of 848x600 at 61 Hz.
Once I started, the user switcher was aborted (as usual) I suspect that is due to my starting with 'startx' rather than a login.

Trying to switch screen modes, I found a selection of

  800x600 (4:3) 61 Hz
  848x480 (16:9) 0 Hz !!!!! <== clearly an error
  640x480 (4:3) 60 Hz

I've attached a Xorg.0.log file.

No selection provided the monitor's max format of 1024 x 768.

I should try the xorg.conf file with a specified resolution range.

The date in the log file is in UTC - I hadn't set the time zone.

It can be seen in the log that X started with the "vesa" driver - the one used by "failsafe mode", instead of the debug savage driver. I don't know why, it worked fine with my own savage laptop. Well, I now included the debug stuff in the new xserver-xorg-video-savage 2.2.1+git20081230.aea0496f-0ubuntu0tormod2 in my PPA (for Jaunty), please try that one instead of the one I attached.

The vesa driver falls back to reasonable default sync ranges, that's why it comes up in 848x600.

Yes, the user switcher will be confused when using startx, nothing to worry about.

What did you use for "trying to switch screen modes"? The "Screen Resolution" preferences? Can you please attach the output from "xrandr --verbose"? Maybe we need to file a vesa bug about that "0 Hz" you saw here. Or the vesa information in the card bios is broken...

This evening I repeated the experiment, this time with my old xorg.conf file containing explicit driver settings, such as:

Section "Device"
        Identifier "S3 Inc. VT8375 [ProSavage8 KM266/KL266]"
        Driver "savage"
        BusID "PCI:1:0:0"
        Option "ModeDebug" "true"
EndSection

Section "Monitor"
        Identifier "Generic Monitor"
        Option "DPMS"
        HorizSync 28-51
        VertRefresh 43-60
EndSection

Section "Screen"
        Identifier "Default Screen"
        Device "S3 Inc. VT8375 [ProSavage8 KM266/KL266]"
        Monitor "Generic Monitor"
        DefaultDepth 16
        SubSection "Display"
                Depth 1
                Modes "1024x768" "800x600" "640x480"
        EndSubSection

... and so on ..... (file sent earlier).

The Monitor Resolution Dialog shows the possible settings

   1024x768
   800x600
   640x480
   512x384
   400x300
   512x384

all (4:3), all 60 Hz.

I think the xorg.conf generated when the system started up in failsafe mode specifies "vesa" just because the system was started in failsafe mode. So I should have changed "vesa" to "savage".

Now my xorg.conf with all the screen parameters does specify "savage", so the right driver would have been used.

So my next step will be to restart in safe text mode, producing the default xorg.conf, edit that to specify "savage", reinstall the new driver xserver-xorg-video-savage 2.2.1+git20081230.aea0496f-0ubuntu0tormod2, and see what I get.

The simplest is if you boot with the "text" parameter, leave the xorg.conf as it is (savage should be picked anyway) and install and run the new driver.

1) I tried first editiing the original xorg.conf, changing 'vesa' to 'savage'.

2) Then I tried the above way: booting with "text", but not specifying safe mode.

In each case, a compatible screen mode was not found, and the X server failed to start.

Here, I have attached the log file for the first case.

Log file for second case

Thanks, that was successful! I think we are circling in on the issue. This graphic card is a laptop chipset and usually has an LCD connected. The driver is able to detect that the LCD is not there, but looks up the sync range information from the panel driver anyway, which is just nulls. This is added to the mode pool, which otherwise is empty since EDID was not retrieved. Also, since the pool now is not empty, the default range is not added.

I'll try to come up with a real fix for this.

Thanks!

Now I'm going to revisit bug #255561 - which refers to the same Samsung display but a different display card on a Dell machine.

Please test the 2.2.1+git20081230.aea0496f-0ubuntu0tormod3 in my PPA. It should fix the invalid (0 Hz) mode issue, so X should start with the default sync ranges (using the default xorg.conf or none at all).

Not having EDID info, and thus not starting in the monitor's 1024x768 mode is a separate issue, I guess that's covered in bug 255561. Please attach the read-edid testing results there.

BTW, please test as before using the kvm switch (which you didn't mention here...). This particular bug only kicks in when there is no EDID.

I just ran the 2.2.1+git20081230.aea0496f-0ubuntu0tormod3 driver, and it started into 800x600 mode (with allowable modes
 800x600, 640x480, .... ). At the moment I have the monitor plugged directly into the gBox computer. I'll retry with the kvm switch.

I got the same resolutions with the monitor plugged back into the kvm switch. Another log appended!

"MiniView" 2-port KVM

Thanks, the two logs are practically identical, so maybe the kvm switch is not at fault for the missing EDID info. Do you have any other special arrangements, like socket adapters or long cables? This belongs to the other bug though.

Anyway, it confirmed that my patch worked, since it came up with the default sync ranges instead of failing to start. I'll have it reviewed upstream, and leave this bug open until a fix gets into the Ubuntu version.

When I connected without the KVM switch, I used no special cables or adapters - the monitor's cable was plugged directly into the gBox computer.

By the way I haven't recorded the output of the get-edid | parse-edid on the gBox - I couldn't install those for Jaunty and the installed system on that computer is Debian 5.0, and somehow the redirection for the output to stdout (to a file) isn't working right under the Debian bash. However it did work under intrepid on my Dell server (bug # 255561), but I don't think the cable is long enough to reach that system.

Can you please file a new bug with the "0 Hz" mode seen with the VESA driver in comment #41?

This page gives the supported modes for this Samsung TFT monitor:

http://www.pcstats.com/articleview.cfm?articleid=610&page=5

Resolution Freq Hor. Freq Ver. Pixel Clock Standard
640x350 31.5kHz 70Hz 25.2MHz VGA
720x400 31.5kHz 70Hz 28.3MHz VGA
640x480 31.5kHz 60Hz 25.2MHz VGA
640x480 37.5kHz 75Hz 31.5MHz VGA
640x480 35.0kHz 67Hz 30.2MHz MAC
800x600 35.2kHz 56Hz 36.0MHz SVGA
800x600 37.9kHz 60Hz 40.0MHz SVGA
800x600 46.9kHz 75Hz 49.5MHz SVGA
832x624 49.7kHz 75Hz 57.3MHz MAC
1024x768 48.4kHz 60Hz 65.0MHz XGA
1024x768 56.5kHz 70Hz 75.0MHz XGA
1024x768 60.0kHz 75Hz 78.8MHz XGA

Here's an Xorg.0.log file from booting Knoppix 5.1 on this gBox computer.

Available screen modes in the knoppix utility for switching modes were 1024x768, 800x600, 640x480, all around 75 Hz.

Here's the xorg.conf file running Knoppix 5.1 on the gBox

Patch accepted upstream.

http://cgit.freedesktop.org/xorg/driver/xf86-video-savage/commit/?id=0fae48235841f05d7e52e61a2450835fdb8892b3

How do I build this? Should I build this under Jaunty or is an earlier
Ubuntu Ok for the build?

Also, should I still file the bug about the 0 Hz scan under the VESA
driver, and should I use the default xorg.conf or none at all for that
test? - I'm not positive about which I did for that test.

On Thu, Jan 22, 2009 at 12:30 AM, Tormod Volden
<email address hidden> wrote:
> http://cgit.freedesktop.org/xorg/driver/xf86-video-
> savage/commit/?id=0fae48235841f05d7e52e61a2450835fdb8892b3
>
> --
> No signal with Samsung SyncMaster 570s and ProSavage8
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

You don't need to build it, it's the same patch as in my PPA.

Yes, please file that vesa bug. Default or no xorg.conf should in principle be the same, but you will need one in order to specify the "vesa" driver!

I just filed the 0 Hz screen mode on "vesa' - # 320313 - first against "intrepid" I will then reproduce it with "jaunty"

This bug was fixed in the package xserver-xorg-video-savage - 1:2.2.1-4ubuntu2

---------------
xserver-xorg-video-savage (1:2.2.1-4ubuntu2) jaunty; urgency=low

  * Cherry-pick 0fae48235841f05d7e52e61a2450835fdb8892b3
    Do not add panel modes when there is no panel.
    Fixes startup failure in some cases (LP: #294899)

 -- Tormod Volden <email address hidden> Fri, 20 Mar 2009 19:56:24 +0100

I was able to boot the Ubuntu 9.04 Beta live (desktop) CD, and X came up properly.

However, screen resolutions were limited to 800x600, 640x480, 400x300, and 320x240.

I have attached the Xorg.0.log file.

I expect to try to use an old xorg.conf file, to force the 1024x768 mode supported by the Samsung SyncMaster 570S TFT monitor.

I tried using an xorg.conf file which specifies screen resolutions up to 1024x768, and that didn't work - the Samsung display just kept showing its "display resolution not supported" popup all over the screen.

So possibly the fixed driver for 8.x versions hasn't been incorporated into 9.04 Beta?

What is the fixed driver for 8.x versions? The fix for this bug is in Jaunty with -savage 1:2.2.1-4ubuntu2.

Should I file a separate bug in the resolution issue (for 9.04 beta) -
that I can't get the display to run at 1024x768?

On Thu, Apr 16, 2009 at 12:20 AM, Tormod Volden
<email address hidden> wrote:
> What is the fixed driver for 8.x versions? The fix for this bug is in
> Jaunty with -savage 1:2.2.1-4ubuntu2.
>
> ** Bug watch added: Debian Bug tracker #520547
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520547
>
> ** Changed in: xserver-xorg-video-savage (Debian)
>   Importance: Unknown => Undecided
>
> ** Changed in: xserver-xorg-video-savage (Debian)
>       Status: Unknown => New
>
> ** Changed in: xserver-xorg-video-savage (Debian)
>  Remote watch: Debian Bug tracker #520547 => None
>
> ** Changed in: xserver-xorg-video-savage (Debian)
>       Status: New => Fix Released
>
> ** Bug watch added: Debian Bug tracker #520547
>   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=520547
>
> ** Changed in: xserver-xorg-video-savage (Debian)
>   Importance: Undecided => Unknown
>
> ** Changed in: xserver-xorg-video-savage (Debian)
>       Status: Fix Released => Unknown
>
> ** Changed in: xserver-xorg-video-savage (Debian)
>  Remote watch: None => Debian Bug tracker #520547
>
> --
> BFe:  No signal with Samsung SyncMaster 570s and ProSavage8 [patch]
> https://bugs.launchpad.net/bugs/294899
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Yes please, we can not track that issue in this report (which was a different issue and is now closed).

Actually, I was in error regarding the resolution. I used the wrong procedure for getting a modified xorg.conf to work.

Editing the xorg.conf file, logging out, then logging back in sets the resolution to 1024x768 (see also bug 255561, with the same monitor but a different computer and display card).

So this is solved, but of course a tool for modifying xorg.conf would be very useful.

Thanks for all your help!

I have now tried this with the Ubuntu 9.04 rc live disk:

I have attached an xorg.conf file which sets the following screen resolutions, after switching to a console and executing

  sudo service gdm restart

1024x768 (new)
800x600
640x480
512x384 (new)
400x300
320x240

This also works with the Kubuntu 9.04 rc live disk.

The only difference is that

  sudo service kdm restart

restarts X, enabling the new xorg.conf file.

Do you need to add anything else than the H and V sync ranges? Anyway, isn't this discussed in bug 255561?