<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - No signal to monitor with X and openchrome using VX855 chipset graphics" href="https://bugs.freedesktop.org/show_bug.cgi?id=91966#c216">Comment # 216</a> on <a class="bz_bug_link bz_status_REOPENED " title="REOPENED - No signal to monitor with X and openchrome using VX855 chipset graphics" href="https://bugs.freedesktop.org/show_bug.cgi?id=91966">bug 91966</a> from <a class="email" href="mailto:kevinbrace@gmx.com" title="Kevin Brace <kevinbrace@gmx.com>"> Kevin Brace</a> <pre>(In reply to Justin Chevrier from <a href="show_bug.cgi?id=91966#c211">comment #211</a>) Hi Justin, > > Regarding VX900's native support for DVI (I am assuming that VX900 > > chipset actually has an integrated TMDS transmitter.), I will make a patch > > that will temporarily activate LCD screen for HP T5550 or disable the use of > > this weird table for certain models with integrated TMDS transmitters like > > VX900 chipset. > > I hope this will make OpenChrome to run through the code that detects DVI > > using its integrated TMDS transmitter. > > I tweaked the T5550 entry (I've attached the patch) and as you suspected > enabling the LCD device allowed the monitor connected via DVI to be detected > and function via the DVI-I port (log attached). The DVI-D connector remained > non-functional. The monitor connected with a VGA cable via the DVI to VGA > adapter was still detected, but no longer displayed anything (log attached). Well, at least there is some good news that the weird known device table was the culprit as I have guessed. It now appears that DVI-I's DVI portion comes from VX900's integrated TMDS transmitter, and VT1632A TMDS transmitter chip is connected to I2C bus 3. When the code to support VT1632A was donated, it had a strange assumption that VT1632A detection was done only when P4M800 Pro, VN800, or CN700 chipset is present. I took out this assumption, but to complicate the situation, I2C bus 3 is not a hardware based I2C implementation like I2C bus 1 and 2. I do not know how proven the I2C bus 3 controlling code really is. If your thin client's VT1632A was connected to I2C bus 2, it would have been a different story, as I have seen 2 different people able to get OpenChrome to recognize VT1632A on I2C bus 2 (i.e., OpenChrome is able to get vendor ID match on I2C bus 2) recently. I will likely develop a patch that will use look into what is being sent over I2C bus 3 since OpenChrome is not getting vendor ID match over I2C bus 3 in your situation. Without vendor ID match, OpenChrome will assume that VT1632A is not connected. As for the DVI to VGA adapter not working well, again, that is bad. I will try to think of a something for you to try in the next few days.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> </ul> </body> </html>