Current setup OpenChrome 0.5.130 Wyse Cx0 When using VGA only, the display works fine. When using DVI only, The display works fine. When using both DVI and VGA with the "Y" adapter, the VGA screen works, but the DVI doesn't. ARandR shows "VGA-1" active, but on "DVI-2" active is grayed out. In the past, I believe "VGA-1" and "DVI-1" showed up. I will test this on another monitor shortly.
Created attachment 125854 [details] Xorg.0.log 0.5.130 Cx0 DVI only
Created attachment 125855 [details] Xorg.0.log 0.5.130 Cx0 VGA only
Created attachment 125856 [details] Xorg.0.log 0.5.130 Cx0 both DVI+VGA "Y" adapter
Tried it on an HDMI TV with both DVI and VGA using the VGA+DVI "Y" and a DVI-HDMI adapter on the DVI part of the "Y". Worked fine.
Created attachment 125860 [details] Xorg.0.log 0.5.130 Cx0 both DVI+VGA "Y" adapter with HDMI adapter on DVI
Ok, well this might have been caused by a bad cable. After it worked on the HDMI TV, I tried a different DVI cable and all seems to be fine. I put the "bad" cable back on the "Y" and no DVI Funny thing is it worked with fine with the bad cable on DVI only (I just unplugged the VGA cable from the "Y"). Please examine the log files to make sure there isn't some overlooked quirk and then you can close this bug.
Created attachment 125861 [details] Xorg.0.log 0.5.130 Cx0 both DVI+VGA "Y" adapter both working-different cable Attachment 125854 [details], 855, 856 and this one using LG Flatron W2242P Attachment 125860 [details] using Vizio HDMI TV.
Ok, so after further testing, I believe there is some problem, either with my monitor or with OpenChrome. Monitor: LG Flatron W2242P When I boot with both DVI and VGA using the "Y" cable: If I have the monitor source on DVI while booting both DVI and VGA work. If I have the monitor source on VGA while booting, only the VGA works.
Created attachment 125862 [details] Xorg.0.log 0.5.130 Cx0 both DVI+VGA "Y" adapter W/monitor boot source VGA Attachment 125861 [details] was posted and then I shutdown and rebooted the machine without changing anything except setting the monitor source to VGA DVI does not work. This is the Xorg.0.log from the reboot.
Hi Eric, Sorry for the slow response. I hate to say this, but after reading the DVI specification looking at the pin assignment, it appears that there is only one I2C bus per DVI-I connector. What this means is that if there are 2 devices connected to the DVI-I connector, the behavior is undefined. (unpredictable) This is probably why DVI to VGA adapter is used all the time rather than DVI and VGA "Y" cable, which is very rare. I will treat this as something I will consider "unsupported," but obviously, I will not try to write code that will undermine the use of the a DVI and VGA "Y" cable. Since I did major rewriting of DVI related code and I do not have access to Wyse Cx0 for now (I still own it, obviously.), I wanted to see how the new code fared. Regarding the "DVI-2" display you observed, that one is my laziness (i.e., it's a feature, not a bug) where I hardcoded "DVI-2" into the code for now. I am planning to make this numbering programmable, so that it can correctly display "DVI-1," "DVI-2," etc. As a general rule, an integrated TMDS transmitter will always be assigned (i.e., "DVI-1") before external TMDS transmitters are assigned as "DVI-2," "DVI-3," etc. I will definitely fix this before the official OpenChrome Version 0.6 release. I will start working on this in the next few days so that it does not linger any longer. Regarding the DVI code, there is still some code where I am still hardcoding settings that make it work with mainly Wyse Vx0 thin client. (i.e., I am assuming VT1632A is located at DVP0.) I will like to make this general purpose since this situation is not desirable.
Hi Eric, Just for your information, the present OpenChrome code uses VT1632A's TMDS receiver detection capabilities. In other words, if VT1632A does not detect a TMDS receiver on the other end (i.e., a monitor with DVI), OpenChrome will not obtain EDID from that particular monitor. If you see the following message in the log file, then VT1632A is not seeing the TMDS receiver. ______________________________________________________________________________ [ 52.415] (II) CHROME(0): Entered viaVT1632Sense. [ 52.421] (II) CHROME(0): VT1632 did not detect a TMDS receiver. [ 52.421] (II) CHROME(0): Exiting viaVT1632Sense. ______________________________________________________________________________
Hi Eric, This is my best current understanding of how DVI-I connector works. DVI-I has both DVI signals and analog VGA signals. However, it has only one I2C bus. Within OpenChrome, when an EDID is obtained from the monitor, the code looks for whether or not the returned EDID is an analog type or digital type. If an analog type is returned, it is safe to assume analog VGA presence. However, if a digital type EDID is returned, it is a little tricky since a digital type EDID can be an LVDS flat panel. (i.e., laptop LCD monitor, not the typical desktop LCD monitor) or DVI. For now, I discontinued the use of I2C bus for LVDS flat panel due to conflicts with DVI code. The LVDS flat panel code is now 100% dependent on BIOS based interface to tell OpenChrome the panel resolution. I do not necessarily like this implementation, but it is what I have now. Some LVDS flat panel do not have an I2C bus coming out of it. I recently updated the flat panel screen resolution table due to this LVDS flat panel and DVI conflict issue.
Hi Eric, The "DVI-2" thing you noticed was just fixed by Version 0.5.136. This particular commit fixed the issue. https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=ef42c82ede738d064d8bf6285fbb780d41afc3a4 If you do not see DVI-1 when you have DVI, let me know Again, I was hoping no one would have noticed my laziness. I will likely reuse the same code for analog VGA and FP in the near future.
-- 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/21.
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.