|Summary:||[NV4C] GeForce 6150SE: external DVI encoder not supported (Sil1364)|
|Product:||xorg||Reporter:||Frank Schaefer <fschaefer.oss>|
|Component:||Driver/nouveau||Assignee:||Nouveau Project <nouveau>|
|Status:||RESOLVED MOVED||QA Contact:||Xorg Project Team <xorg-team>|
|i915 platform:||i915 features:|
Description Frank Schaefer 2010-02-28 03:09:20 UTC
Nouveau doesn't detect the DVI-connector of my GeForce 6150SE (Asus M2N-VM DH). The screen turns black during boot-process immediately after the "[drm] nouveau ..." messages appeared. The board has two connectors (DVI + VGA) and I'm using the DVI-connector only. Everything is fine when I use a VGA-cable instead. Tested with kernel 2.6.33.
Comment 2 Frank Schaefer 2010-02-28 03:28:56 UTC
I've sent the requested mmio-trace.
Comment 3 Francisco Jerez 2010-03-04 07:52:24 UTC
Created attachment 33758 [details] [review] dcb_type_4_hack.patch Bad news... The TMDS tables in your BIOS are stale and do *not* describe how to set up this external TMDS encoder (instead they describe an integrated encoder that doesn't really exist in your card). It could still be that the modesetting process is encoded somewhere else using a different bytecode format but I seriously doubt it, the output from this command might give us a clearer answer: # ./vbtracetool -l -d -s 317 2>trace.log You can get vbtracetool here . If you're very lucky the patch I'm attaching will improve things, but probably not: most likely your encoder chip will need its own stand-alone driver.  http://cgit.freedesktop.org/~stuart/vbtracetool/
Comment 4 Frank Schaefer 2010-03-04 11:04:42 UTC
The patch didn't work. :( Are you sure the suggested vbtracetool command is right ? Screen turns black immediately and I get a log of ~2GB !!??
Comment 5 Francisco Jerez 2010-03-04 14:41:30 UTC
(In reply to comment #4) > The patch didn't work. :( > > Are you sure the suggested vbtracetool command is right ? > Screen turns black immediately and I get a log of ~2GB !!?? > That's a bit unexpected but possible, any chance I could have a look at e.g. the first 100MB? You could use "dd" to cut it, like: $ dd if=trace.log of=trace1.log bs=1M count=100 Compression should also make it a good deal smaller.
Comment 6 Frank Schaefer 2010-03-05 05:56:07 UTC
Created attachment 33788 [details] First 100MB of the vb-trace
Comment 7 Frank Schaefer 2010-03-05 06:01:33 UTC
LZMA compresses the whole 2 GB to 14.1 MB (!). So I could send it, too.
Comment 8 Francisco Jerez 2010-03-05 06:14:40 UTC
(In reply to comment #7) > LZMA compresses the whole 2 GB to 14.1 MB (!). > So I could send it, too. > It would be interesting as well. Thanks.
Comment 9 Frank Schaefer 2010-03-05 06:21:43 UTC
As attachment or per mail (like the mmiotrace) ?
Comment 10 Francisco Jerez 2010-03-05 06:34:46 UTC
(In reply to comment #9) > As attachment or per mail (like the mmiotrace) ? > Per mail, preferably to the mmio.dumps account.
Comment 11 Francisco Jerez 2010-03-06 10:04:21 UTC
(In reply to comment #7) > LZMA compresses the whole 2 GB to 14.1 MB (!). > So I could send it, too. > Thanks, that's been useful, but sadly your BIOS does it with a bunch of ad-hoc x86 code, as in the old days. The blob used to let out the names of any external encoders when you gave it a high enough verbosity level. They often have register-level specs available so implementing a driver for it would possibly involve little RE-ing, but still a good deal of work.
Comment 12 Frank Schaefer 2010-03-07 06:18:02 UTC
(In reply to comment #11) > The blob used to let out the names of any external encoders when you gave it a > high enough verbosity level. Is there a way to increase the verbosity level ? Anything else I can do ?
Comment 13 Francisco Jerez 2010-03-07 12:46:43 UTC
(In reply to comment #12) > (In reply to comment #11) > > The blob used to let out the names of any external encoders when you gave it a > > high enough verbosity level. > > Is there a way to increase the verbosity level ? I'd try "Xorg -logverbose 8". > Anything else I can do ? > I'm not sure, making this work will probably involve too much new code to be carried out remotely and not go mad at the same time. :)
Comment 14 Frank Schaefer 2010-03-08 04:05:33 UTC
(In reply to comment #13) > > Anything else I can do ? > > I'm not sure, making this work will probably involve too much new code to be > carried out remotely and not go mad at the same time. :) Well, I can checkout remote repositories/branches for testing ;) The sh.. is, that this GPU is blacklisted by the nv-driver (screen corruption), so people are stuck with VESA when the blob is declared as "legacy" one day (soon ?)...
Comment 15 Frank Schaefer 2010-03-08 04:08:17 UTC
Created attachment 33861 [details] Xorg.0.log with "-logverbose 8" (Nvida driver 195.36.08)
Comment 16 Frank Schaefer 2010-03-08 04:13:37 UTC
The TDMS is a Silicon Image TMDS PanelLink Sil1364ACTU Q6?844.1-1 (? is D/O/0) 0611 AD??KD2 (? is D/O/0) Can't find a datasheet, maybe you have more luck / better connections ;) For reference: the MB is a ASUS M2N-VM DH
Comment 17 Francisco Jerez 2010-03-08 05:32:05 UTC
(In reply to comment #16) > The TDMS is a > > Silicon Image > TMDS PanelLink > Sil1364ACTU > Q6?844.1-1 (? is D/O/0) > 0611 > AD??KD2 (? is D/O/0) > > > Can't find a datasheet, maybe you have more luck / better connections ;) > > For reference: the MB is a ASUS M2N-VM DH > That's interesting, it's an sDVO TMDS transmitter, the intel driver has code  for a similar piece of hardware.  http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/i915/dvo_sil164.c
Comment 18 Frank Schaefer 2010-03-09 05:24:59 UTC
According to +, sDVO is used by nForce430 + Geforce 6150SE nForce430 + Geforce 6100  http://www.nvidia.de/page/legacy_gpu_mobo_tech_specs.html  http://www.nvidia.de/page/gpu_mobo_tech_specs.html
Comment 19 Ilia Mirkin 2013-08-18 18:10:37 UTC
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
Comment 20 Frank Schaefer 2013-08-18 19:48:52 UTC
This bug report still applies to the latest kernel. A driver for the Sil1364 is missing.
Comment 21 Ilia Mirkin 2013-08-18 20:02:56 UTC
Which kernel is the latest kernel? Could you put up a dmesg from it? Also, could you supply your VBIOS? (/sys/kernel/debug/dri/0/vbios.rom)
Comment 22 Frank Schaefer 2013-08-18 20:39:05 UTC
(In reply to comment #21) > Which kernel is the latest kernel? 3.10 I'm on Radeon hardware since then and I can't switch back easily. > Could you put up a dmesg from it? Nothing has changed, DCB type 4 is still unknown. > Also, could you supply your VBIOS? (/sys/kernel/debug/dri/0/vbios.rom) Already sent 3 1/2 years ago. See comments #6-11 Please read the the whole bug report. The reason why the connector doesn't work, is that the DVI connector is realized with a Sil1364 sDVO and there is no driver for it yet. I don't have access to datasheets of the Sil1364. If we have a driver for this device one day, I'll be glad to test it.
Comment 23 Ilia Mirkin 2013-08-18 20:49:09 UTC
I did read the whole bug report. What you attached was not the vbios. The vbios should be ~50-60K. There was support added semi-recently for external encoders (in 3.9), but I just checked and it was only on nv50+.
Comment 24 Ilia Mirkin 2013-08-24 19:13:23 UTC
*** Bug 40138 has been marked as a duplicate of this bug. ***
Comment 25 Martin Peres 2019-12-04 08:23:52 UTC
-- 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-nouveau/issues/6.