Nouveau - Feb 2014 - [Bug 74903] New: TV Load not detected in X

https://bugs.freedesktop.org/show_bug.cgi?id=74903

          Priority: medium
            Bug ID: 74903
          Assignee: nouveau at lists.freedesktop.org
           Summary: TV Load not detected in X
        QA Contact: xorg-team at lists.x.org
          Severity: major
    Classification: Unclassified
                OS: Linux (All)
          Reporter: alexandre.nunes at gmail.com
          Hardware: x86 (IA32)
            Status: NEW
           Version: unspecified
         Component: Driver/nouveau
           Product: xorg

Created attachment 93957
  --> https://bugs.freedesktop.org/attachment.cgi?id=93957&action=edit
Xorg.0.log

I have an ancient computer with a FX 5200 card which is played to an old TV via
composite output. It has been working for ages, until I upgraded the system
(debian) and now when I start X, the tv image goes off.

This setup is using KMS, and IIRC newer kernels had the same problem on module
load. I downgraded the kernel to 3.11.2 and now the framebuffer is working 
fine again (with at least 3.11.6 and newer kernels it's a no-go). But when
starting X, the image is gone and the log tells:

[   164.729] (==) NOUVEAU(0): Swap limit set to 2 [Max allowed 2]
[   164.783] (II) NOUVEAU(0): Output VGA-1 has no monitor section
[   164.843] (II) NOUVEAU(0): Output DVI-I-1 has no monitor section
[   164.896] (II) NOUVEAU(0): Output TV-1 has no monitor section
[   164.950] (II) NOUVEAU(0): EDID for output VGA-1
[   165.003] (II) NOUVEAU(0): EDID for output DVI-I-1
[   165.056] (II) NOUVEAU(0): EDID for output TV-1
[   165.056] (II) NOUVEAU(0): Output VGA-1 disconnected
[   165.056] (II) NOUVEAU(0): Output DVI-I-1 disconnected
[   165.056] (II) NOUVEAU(0): Output TV-1 disconnected
[   165.056] (WW) NOUVEAU(0): No outputs definitely connected, trying again...
[   165.056] (II) NOUVEAU(0): Output VGA-1 disconnected
[   165.056] (II) NOUVEAU(0): Output DVI-I-1 disconnected
[   165.056] (II) NOUVEAU(0): Output TV-1 disconnected
[   165.057] (WW) NOUVEAU(0): Unable to find connected outputs - setting
1024x768 initial framebuffer

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140212/bb4cc6e3/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74903

--- Comment #1 from Alexandre <alexandre.nunes at gmail.com> ---
Created attachment 93958
  --> https://bugs.freedesktop.org/attachment.cgi?id=93958&action=edit
Full dmesg

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140212/2bcc41ef/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74903

Ilia Mirkin <imirkin at alum.mit.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|TV Load not detected in X   |[NV34] TV Load not detected
                   |                            |in X

--- Comment #2 from Ilia Mirkin <imirkin at alum.mit.edu> ---
What happens if you're in X (with the image off) and then try to switch back
to
the console? Does it come on, or is it off forever?

I don't see any relevant changes between 3.11.2 and 3.11.6... would be very
interesitng to know what causes the additional regression -- it should be a
pretty fast bisect, if you're up for it.

What kernel were you using before the upgrade? I'm guessing
"ancient" (like
pre-3.7)?

It would also be interesting to see a dmesg from semi-working boot (i.e.
3.11.2) and X loading, with "nouveau.debug=debug drm.debug=0xe"
options added
to the kernel cmdline.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140212/34285aa9/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74903

--- Comment #3 from Alexandre <alexandre.nunes at gmail.com> ---
(In reply to comment #2)
> What happens if you're in X (with the image off) and then try to switch
back
> to the console? Does it come on, or is it off forever?
It's off forever. But I can't even reproduce this anymore, please keep
reading.
> 
> I don't see any relevant changes between 3.11.2 and 3.11.6... would be
very
> interesitng to know what causes the additional regression -- it should be a
> pretty fast bisect, if you're up for it.
In fact, it's worse: It seems intermitent. I can only get there about 1 in 3
attempts if I cold boot (w kernel 3.11.2, I suspect newer kernels could be the
same thing) (i.e. turn the power off and on again), but never if I just reboot
after getting the "blue screen" from tv.

But here is the strange thing: I tested on another tv and it's ok. Since
this
problematic tv only hits this bug on KMS (intermitent)/xserver w/
nouveau(always happens as far as I've observed), but not on console or vesa
fb,
I suspect it could be related to load detection. 

I tried booting with param video=TV1:e as (poorly) documented way to force tv
on. dmesg log and X log now plays nice as if the tv was indeed connected,
however, I can't see anything past kms trigger.

Is there a way to truly override load detection? As I said, the other tv is
just fine, the dmesg shows tv connected.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140212/eff4c466/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74903

--- Comment #4 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #3)
> I tried booting with param video=TV1:e as (poorly) documented way to force
I think you want TV-1:e.
> tv on. dmesg log and X log now plays nice as if the tv was indeed
connected,
> however, I can't see anything past kms trigger.
> 
> Is there a way to truly override load detection? As I said, the other tv is
> just fine, the dmesg shows tv connected.
There's a nouveau.tv_disable which is listed as "Disable TV-out
detection". I
kind of assume it just ignores the outputs entirely, but who knows. You may
want to peruse drivers/gpu/drm/nouveau/dispnv04/tvnv17.c:nv17_tv_detect

It has special exceptions for a couple of cards with quirks. There's a way
to
return a "status unknown" -- try that?

But it's a little odd that it worked fine before -- what was the
"before"
kernel?

FTR, S-video worked fine on my NV44 last I checked (~kernel 3.11 or so).

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140212/b92915d4/attachment-0001.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74903

--- Comment #5 from Alexandre <alexandre.nunes at gmail.com> ---
(In reply to comment #4)
> (In reply to comment #3)
> > I tried booting with param video=TV1:e as (poorly) documented way to
force
> 
> I think you want TV-1:e.
> 
Sorry for the typo, I was using that. As I said, it makes drm/x sees the
display as existant, but with no video output. Perhaps there could be some
hooking between this higher layer and lower ones (eg. nv17_tv_detect) in order
to maintain coherence. I say that because even tought this option didn't
help,
after your suggestion, I was able to hack into nv17_tv_detect making it return
connector_status_connected whenever it would return disconnected/unknown, and
it's working (for me?). 

> There's a nouveau.tv_disable which is listed as "Disable TV-out
detection".
> I kind of assume it just ignores the outputs entirely, but who knows. You
> may want to peruse drivers/gpu/drm/nouveau/dispnv04/tvnv17.c:nv17_tv_detect
> 
> It has special exceptions for a couple of cards with quirks. There's a
way
> to return a "status unknown" -- try that?
> 
Returning connector_status_unknown wasn't enough, but connected did the
trick.
> But it's a little odd that it worked fine before -- what was the
"before"
> kernel?

I'm not sure anymore, but it wasn't so ancient. 3.8.x perhaps. I'll
leave the
(dirty, bad mannered) patch attached just in case someone else as lazy as me
happens to find this report. 

The patch doens't fix the issue, only works around it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140213/8a051005/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74903

--- Comment #6 from Alexandre <alexandre.nunes at gmail.com> ---
Created attachment 94012
  --> https://bugs.freedesktop.org/attachment.cgi?id=94012&action=edit
dirty work-around that forces the tv output as enabled

this was against vanilla kernel 3.13.2

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140213/b358d5ce/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74903

--- Comment #7 from Ilia Mirkin <imirkin at alum.mit.edu> ---
(In reply to comment #5)
> (In reply to comment #4)
> > But it's a little odd that it worked fine before -- what was the
"before"
> > kernel?
> 
> I'm not sure anymore, but it wasn't so ancient. 3.8.x perhaps.
I'll leave
> the (dirty, bad mannered) patch attached just in case someone else as lazy
> as me happens to find this report. 
Would you be willing to

(a) Verify whether 3.8.x was indeed good? There aren't a whole lot of
changes
to the nv17 tv file since 3.8...
(b) Do a bisect between the good version and 3.13 (restricted to
drivers/gpu/drm/nouveau, so shouldn't be _too_ bad, but maybe like 10
steps).

Happy to provide help with the bisect if you're not sure how to do it.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/nouveau/attachments/20140216/0b5877e4/attachment.html>

https://bugs.freedesktop.org/show_bug.cgi?id=74903

Alexandre <alexandre.nunes at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- Comment #8 from Alexandre <alexandre.nunes at gmail.com> ---
I'm taking this bug report away since I don't even have access to that
system
anymore.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/nouveau/attachments/20170630/1ce301e3/attachment.html>