Created attachment 124868 [details] CN700 + VT1632, DVI connected screen not detected. An MSI Fuzzy CN700G mainboard with VGA + DVI-D output doesn't detect a screen connected to the DVI port (HDMI on the screen's end). The chipset is a CN700 coupled with a VT1632. Fully up to date Fedora 23 + openchrome 0.5 rc8.
Hi Xavier, If you read the log carefully, you can see that I2C bus 3 is seeing VT1632A. ________________________________________________________________________ . . . [ 380.402] (II) CHROME(0): Entered via_dvi_init. [ 380.402] (--) CHROME(0): Will probe I2C Bus 3 for a possible external TMDS transmitter. [ 380.402] (II) CHROME(0): I2C device "I2C Bus 3:VT1632A" registered at address 0x10. [ 380.402] (II) CHROME(0): Entered via_vt1632_probe. [ 380.404] (II) CHROME(0): Vendor ID: 0x1106 [ 380.409] (II) CHROME(0): Device ID: 0x3192 [ 380.414] (--) CHROME(0): VT1632A DVI transmitter detected. [ 380.414] (II) CHROME(0): Exiting via_vt1632_probe. [ 380.414] (II) CHROME(0): Entered via_vt1632_init. [ 380.418] (II) CHROME(0): VT1632A Dot Clock Range: 25 to 165 MHz [ 380.418] (II) CHROME(0): Entered via_vt1632_dump_registers. [ 380.418] (II) CHROME(0): VT1632A: dumping registers: [ 380.419] (II) CHROME(0): VT1632A: 0x00: 0x06 [ 380.421] (II) CHROME(0): VT1632A: 0x01: 0x11 [ 380.426] (II) CHROME(0): VT1632A: 0x02: 0x92 [ 380.431] (II) CHROME(0): VT1632A: 0x03: 0x31 [ 380.433] (II) CHROME(0): VT1632A: 0x04: 0x00 [ 380.434] (II) CHROME(0): VT1632A: 0x05: 0x00 [ 380.435] (II) CHROME(0): VT1632A: 0x06: 0x19 [ 380.436] (II) CHROME(0): VT1632A: 0x07: 0x64 [ 380.444] (II) CHROME(0): VT1632A: 0x08: 0x3b [ 380.447] (II) CHROME(0): VT1632A: 0x09: 0x06 [ 380.448] (II) CHROME(0): VT1632A: 0x0a: 0x00 [ 380.449] (II) CHROME(0): VT1632A: 0x0b: 0x00 [ 380.450] (II) CHROME(0): VT1632A: 0x0c: 0x00 [ 380.455] (II) CHROME(0): VT1632A: 0x0d: 0x80 [ 380.457] (II) CHROME(0): VT1632A: 0x0e: 0x00 [ 380.460] (II) CHROME(0): VT1632A: 0x0f: 0x00 [ 380.460] (II) CHROME(0): Exiting via_vt1632_dump_registers. [ 380.460] (II) CHROME(0): Exiting via_vt1632_init. . . . ________________________________________________________________________ Furthermore, it is detecting the presence of DVI. ________________________________________________________________________ . . . [ 380.517] (II) CHROME(0): Entered via_vt1632_detect. [ 380.520] (II) CHROME(0): VT1632A: DVI device is detected. [ 380.520] (II) CHROME(0): Exiting via_vt1632_detect. [ 380.520] (II) CHROME(0): I2C device "I2C Bus 3:ddc2" registered at address 0xA0. [ 380.529] (II) CHROME(0): EDID for output DVI-1 [ 380.529] (II) CHROME(0): Output VGA-1 disconnected [ 380.529] (II) CHROME(0): Output TV-1 disconnected [ 380.529] (II) CHROME(0): Output DVI-1 disconnected [ 380.529] (WW) CHROME(0): No outputs definitely connected, trying again... [ 380.529] (II) CHROME(0): Output VGA-1 disconnected [ 380.530] (II) CHROME(0): Output TV-1 disconnected [ 380.530] (II) CHROME(0): Output DVI-1 disconnected [ 380.530] (WW) CHROME(0): Unable to find connected outputs - setting 1024x768 initial framebuffer . . . ________________________________________________________________________ This appears to be EDID is not being returned properly to the host (i.e., CN700 chipset). If you have a "true" DVI input monitor, that might be a better equipment to test against.
Hi Xavier, Actually, auctioned off a mainboard like this on ebay recently. I will have access to it once I get back from where I am staying at. It is a triple head model (VGA + DVI + TV), and I do not believe the current OpenChrome code can handle a triple head situation properly.
Created attachment 124871 [details] [review] Test setting up I2C bus 3 differently
Hi Xavier, You can try the patch to see if it makes a difference. I do not own a board that uses I2C bus 3, so it is still fairly unproven. As long as EDID is not coming back from the monitor, OpenChrome cannot move forward, and this is why you do not see anything on the screen. At my place, I have verified that VT1632A is working with Wyse Vx0 and Cx0 thin clients. They both use I2C bus 2 to communicate to VT1632A.
Hi Kevin, No difference with the patch, apart from the missing "(II) CHROME(0): using alternative PutBits/GetBits functions for I2C Bus 3" line in the log, indeed. I unfortunately don't have a monitor with DVI input, only VGA and HDMI. I'll look at borrowing one if possible.
(In reply to Xavier Bachelot from comment #5) Hi Xavier, > Hi Kevin, > > No difference with the patch, apart from the missing "(II) CHROME(0): using > alternative PutBits/GetBits functions for I2C Bus 3" line in the log, indeed. > I unfortunately don't have a monitor with DVI input, only VGA and HDMI. I'll > look at borrowing one if possible. Since this bug report came in at the very end of OpenChrome Version 0.5 RC testing process, I will go ahead and make OpenChrome Version 0.5 RC8 the release version. Assuming that this is not a hardware problem and it is a bug, I will work on it during the Version 0.6 development process. I already have one bug fix that will go into Version 0.6 ready to be committed.
Hi Xavier, I received the same exact board you are using here. However, due to a personal reason, I will not have access to it for the foreseeable future. I believe the hardware is okay. (I have not tested it yet.) If you can try the code with a straight DVI cable, I can take a second look at the bug.
Hi Xavier, If you can test the updated DVI detection code, that will be helpful. I currently do not have the equipment to test the code against VT1632.
Hi Xavier, I did receive the same board in question, but due to a personal event that happened to me, I do not have access to it until October. If you have the hardware with a straight DVI cable, please test the code.
Xavier, I made some improvements in supporting DVI of MSI Fuzzy CN700G mainboard. The reason the code never worked well is because, 1) VT1632A DVI transmitter's I2C bus is connected to GPIO pins 2) GPIO based I2C bus appears to suffer from communication issues 3) There are issues with older X Server's I2C bus handling Try the latest version code (Version 0.6.175) which improves the issues, although there are still some issues with standby resume.
If I were to add one more thing, OpenChrome DRM appears to have better GPIO based I2C bus control code than OpenChrome DDX. Yesterday, I was able to get OpenChrome DRM to properly readout EDID from a fairly high screen resolution Samsung monitor (it supports 1680x1050). Although the code has not been committed, I did write code for OpenChrome DRM to support VT1632(A). However, the code suffers from strange color issues, so it has not been committed at this point.
Xavier, if you can, try running the code with OpenChrome DRM. I recently added the to support VT1632(A). Furthermore, I tested OpenChrome DRM on Wyse Vx0 thin client and DVI works. As for MSI CN700G mainboard, it appears that current OpenChrome DDX's I2C bus code for GPIO based I2C bus has issues, and EDID is not coming back to the chip properly. The current GPIO based I2C bus code is able to recognize VT1632(A), but not the monitor itself. I will start working on this issue next month.
-- 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/openchrome/old-bug-database/issues/20.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.