Hi Damian

Would you mind providing a bit more information in a slightly easier format

* Logs (see bugs[1] section for which ones and how to obtain them)
* What connection are you using for your TV - vga,dvi,dp,hdmi
* Is there any other display device connected - LVDS, monitor,...?
* What tool do you use to get the list of resolutions/change the resolution

Please provide a single set of logs, they should include
* System startup with the TV plugged it
* Your attempt to change the resolution
* Reconnecting the TV and setting up the correct resolution


Emil

[1] http://nouveau.freedesktop.org/wiki/Bugs

* Logs (see bugs[1] section for which ones and how to obtain them)
Hmm...but this is specific to nouveau driver, this problems is at least with vesa, nv, nouveau, nVidia binary driver, more like an X infrastructure problem because it do not detect the resolution, but as you wish I'll post them in the next comment.

* What connection are you using for your TV - vga,dvi,dp,hdmi
-VGA.

* Is there any other display device connected - LVDS, monitor,...?
-No.

* What tool do you use to get the list of resolutions/change the resolution
-Krandrtray, gnome-display-properties, nvidia-setting (all with same result)

Created attachment 48473 [details]
normal startup with monitor

Created attachment 48474 [details]
startup with TV

In the first sentence in my last comment I mean it's NOT specific to nouveau, sorry. Log's attached.

* Your attempt to change the resolution
* Reconnecting the TV and setting up the correct resolution
Resolution changes fine. X not find higher available resolutions than 1024x768 on the TV. 
"Reconnecting the TV and setting up the correct resolution" - Don't know if this is even succesfully since I plug out my monitor and put the TV in and X thinks it's still the monitor and the output do not look very smooth.

AFAIK nvidia's binary driver detects the supported resolutions irrespectively of X

Thus I do not believe it's X infrastructure related

Now if we consider the case
"nouveau sets 800x600 upon boot, whereas nvidia does 1024x768"

You can clearly see that this is _not_ the case by looking at your log
"...nouveau 0000:01:00.0: allocated 1024x768..."

Nevertheless your Xorg.0.log should provide you with list of all the resolutions parsed from the tv/monitor's EDID block

Note that if for some reason the EDID block fetched under Linux differs from the one under windows, that would explain your issue.

If you prefer to use nouveau I highly recommend using more recent(latest git) components [1][2][3]


Emil

[1] http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/
[2] http://cgit.freedesktop.org/mesa/drm/
[3] http://cgit.freedesktop.org/nouveau/linux-2.6/

Just add one of these repositories (I assume openSUSE_11.3 is the right for you), install fitting drm-nouveau-kmp-{flavor} package and update the other packages:

http://download.opensuse.org/repositories/home:/jobermayr/

Then you will use latest - and more or less supported - graphics drivers stack which is much more stable than the half year old thing openSUSE delivers (my experience).

Sorry - twiddled fingers. I meant openSUSE_11.4 with drm-nouveau-kmp-default should fit. But don't mix X11:XOrg repo with packages from this repository/project!

(In reply to comment #8)
> Sorry - twiddled fingers. I meant openSUSE_11.4 with drm-nouveau-kmp-default
> should fit. But don't mix X11:XOrg repo with packages from this
> repository/project!

Done. This do NOT fix the problem. Only KDE-Plasma-Desktop hangs :)

Can I provide something else to help?

Hi Damian

As previously suggested your issue could be related to the EDID

Thus can you obtain your TV's EDID [1] and [2] as well as Xorg.0.log [3]

* System start with the TV (resolution of 800x600)
* Disconnect the monitor and connect the TV ("I can use all! resolutions")


Thanks
Emil


[1] cat /sys/class/drm/cardXX-YYYY/edid > edid.bin
Where XX is the card number (0,1,3..)
YYYY is the connector used (VGA, DVI, HDMI...)

[2] http://polypux.org/projects/read-edid/

[3] /var/log/Xorg.0.log

XXXXX@XXXXXXX:~> sudo ls /sys/class/
root's password:
ata_device  backlight  bsg  firmware  hidraw       input  mdio_bus  msr      power_supply  regulator    scsi_disk     sound       tty  video4linux
ata_link    bdi        dma  gpio      hwmon        leds   mem       net      ppdev         rtc          scsi_generic  spi_master  usb  vtconsole
ata_port    block      dmi  graphics  i2c-adapter  lirc   misc      pci_bus  rc            scsi_device  scsi_host     thermal     vc

XXXXX@XXXXXXXX:~> sudo ls /sys/class/graphics/
fb0  fbcon

sorry my fault, I am using now nvidia driver, trying later when installing nouveau...

It appears that this bug report has laid dormant for quite a while. Sorry we haven't gotten to it. Since we fix bugs all the time, chances are pretty good that your issue has been fixed with the latest software. Please give it a shot. (Linux kernel 3.10.7, xf86-video-nouveau 1.0.9, mesa 9.1.6, or their git versions.) If upgrading to the latest isn't an option for you, your distro's bugzilla is probably the right destination for your bug report.

In an effort to clean up our bug list, we're pre-emptively closing all bugs that haven't seen updates since 2011. If the original issue remains, please make sure to provide fresh info, see http://nouveau.freedesktop.org/wiki/Bugs/ for what we need to see, and re-open this one.

Thanks,

The Nouveau Team

I have the same problem now with free radeon driver on openSUSE 13.1 as well as on Fedora 19.

Same problem now with free radeon driver (still problem was never fixed) on openSUSE 13.1 and Fedora 19.

(In reply to comment #15)
> I have the same problem now with free radeon driver on openSUSE 13.1 as well
> as on Fedora 19.

Please attach your xorg log and dmesg output.  Also, I'd suggest opening a new bug for radeon rather than just changing the component.  If you are getting this problem with both nouveau and radeon, I suspect your monitor may have a buggy edid.

What should I do if the EDID is buggy. Is there some hwdb where I can send working modes or something like this? Or is it "it has a buggy edid whatever, they should fix there edid, we don't casre". I'm just asking out of curiosity because this one works on windows 7 but I have another Full HD LCD TV that neither reports correct edid to any OS.

(In reply to comment #18)
> What should I do if the EDID is buggy. Is there some hwdb where I can send
> working modes or something like this? Or is it "it has a buggy edid
> whatever, they should fix there edid, we don't casre". I'm just asking out
> of curiosity because this one works on windows 7 but I have another Full HD
> LCD TV that neither reports correct edid to any OS.

We can add a quirk to the kernel to fix up the EDID if it's buggy.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/22.