Bug 95059

Created attachment 123138 [details]
UMS 0.4.0 thin clients test result with DVI port

For HP T5550 DVI-I and C90LE DVI-I failure case, because we can not enter into command mode and no ssh connection is there, so no logs collected for them.

Thanks,
Frank

An update for this issue:

   We did double check for our thin client platforms again and because we made a wrong test record before(use KMS result), so right now we update the result again below with UMS 0.4.0 driver test:

                              DVI-I            DVI-D
HP T510(VX900)                fail             fail
HP T5555(VX900)               fail             fail
Wyse C90LE(VX855)             fail              X 
Wyse V90LE(CN700)             fail              X

   And I will attach the log again. Sorry for previous misleading.

Thanks,
Frank

Created attachment 123294 [details]
T510/T5555/V90LE/C90LE UMS 0.4.0 DVI test result logs

Hi Frank,

I have been doing some experiments on probing strap pins to figure out what type of external transmitter / encoder is connected to the VIA chipset.
That being said, I still have not obtained positive results, so far.
Theoretically, strap pins can provide hints to OpenChrome to aid the automatic detection of a transmitter / encoder.

Created attachment 124119 [details]
Xorg.0.log of V90LE with UMS 0.4.0

hi,I tried ums0.4.0 in V90LE with DVI port,it can't work,from the Xorg.0.log,it seems dvi port can't get the edid data correctly,and I found that in the source code of ddx,the dvi init function has been commented out(ViaOutputsDetect function in via_outputs.c),so I tried to uncomment it,then the edid can be read as in the attachments,but the display still can't work,so my question is that why comment out the via_dvi_init function,and this function seems just point at vt1632a transmiter,so if the board has no vt1632,how to init the dvi port?
hope to get the answer.

(In reply to frank from comment #6)

Hi Frank,

> Created attachment 124119 [details]
> Xorg.0.log of V90LE with UMS 0.4.0
> 
> hi,I tried ums0.4.0 in V90LE with DVI port,it can't work,from the
> Xorg.0.log,it seems dvi port can't get the edid data correctly,and I found
> that in the source code of ddx,the dvi init function has been commented
> out(ViaOutputsDetect function in via_outputs.c),so I tried to uncomment
> it,then the edid can be read as in the attachments,but the display still
> can't work,so my question is that why comment out the via_dvi_init
> function,and this function seems just point at vt1632a transmiter,so if the
> board has no vt1632,how to init the dvi port?
> hope to get the answer.

There is a very simple reason why the code that initializes an external TMDS transmitter (i.e., the code that looks for VT1632A via I2C bus) is currently disabled.
I simply could not get it to work, so I had to disable it for now.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=0748029d3a562283de7aa6120f434a1e80631e05

If you noticed it, the next commit I made after the above one was the release of Version 0.4.0.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=52730d1da4019969fb4cbd13152ffd06b1ee75e2

The real reasons behind disabling the code that deals with an external TMDS transmitter are the following.
Some people needed a newer version of OpenChrome to be bundled with their Linux distributions ASAP (as soon as possible) due to a bug in the previous version (Version 0.3.3) that affect devices that are not registered with a "known device table."

https://bugs.freedesktop.org/show_bug.cgi?id=94130#c12

Also, I have been working on trying to improve OpenChrome since July 2015, and I just wanted to release a new version since fixing all the bugs will probably take years.
The development process was becoming stressful, and I needed to ship something because I was getting fatigued working on this project.
I am okay now, and I continue to work on fixing the code.
    I will give you more technical explanations as to why DVI via VT1632A is not working yet in another post.

(In reply to frank from comment #6)

Hi Frank,

> Created attachment 124119 [details]
> Xorg.0.log of V90LE with UMS 0.4.0
> 
> hi,I tried ums0.4.0 in V90LE with DVI port,it can't work,from the
> Xorg.0.log,it seems dvi port can't get the edid data correctly,and I found
> that in the source code of ddx,the dvi init function has been commented
> out(ViaOutputsDetect function in via_outputs.c),so I tried to uncomment
> it,then the edid can be read as in the attachments,but the display still
> can't work,so my question is that why comment out the via_dvi_init
> function,and this function seems just point at vt1632a transmiter,so if the
> board has no vt1632,how to init the dvi port?
> hope to get the answer.

Okay, here is the promised technical explanation of what is going on.
Previously, the OpenChrome developers used a thing called "known device table" to decide which display output devices (i.e., VGA, DVI, TV, LVDS flat panel, etc.) to initialize and activate during initialization.
As far as I am concerned, this is not the right way to do things anymore, and I completely removed this table for Version 0.4.0.
The development resources are now directed towards automatic detection of display output devices, and I have been doing some research on how to accomplish this.
VIA IGPs do have a thing called pin strappings that can provide "hints" to the graphics device driver regarding what kind of a transmitter / encoder is connected to the IGP.
Furthermore, VIA IGPs do have some hardware level display presence detection hardware integrated with the IGP to help perform display output device presence detection.
    It sounds like an excuse, but I have been hampered by the lack of hardware availability of devices with VT1632A TMDS transmitter.
I do own 2 function devices with VT1632A, but they are both thin client type devices that are hard to do development work on them.
    If you can run the latest OpenChrome from the Git repository, that will be helpful since I did add a functionality to read off the pin strapping recently.
This will help me figure out whether or not VT1632A is connected to DVP0 (sometimes called GDVP0) or DVP1.
DVP (Digital Video Port) is a connection to an external transmitter / encoder, and depending on the configuration of the device, it can be a TV encoder or TMDS transmitter.
I have written some lines of code to activate VT1632A on VX800, VX855, and VX900 chipsets (code has not been committed to the Git repository yet), but when I tested it with VX855 recently, DVI did not work.
I plan to revisit the code in the next few weeks when I "feel" like working on this again.

Just to clarify, I will like to see the Xorg.0.log file with the latest OpenChrome code in the Git repository since the latest version (Version 0.4.157) does have the ability to read off the pin strapping.
This helps me understand which DVP (Digital Video Port) VT1632A is connected to.
I will likely revisit the VT1632A support issue when the bug I am currently trying to fix (i.e., the hang when the screen resolution is changed from the OS) is fixed.

On a minor note, the recent commits do initialize DVP0 and DVP1 transmitters.
I have observed previously that they are not sometimes initialized, and OpenChrome has the responsibility to turn them on, but previous developers were not doing this.
There are also issues like which IGA (display controller) should be dedicated to DVI.
Currently, OpenChrome does not have the ability to dynamically allocate the assigned display controller, and DVI is tricky since it is expected to be assigned to IGA1 or IGA2 depending on what display output device is presently connected.
For example, if an LVDS FP (Flat Panel) is detected, it should always be assigned to IGA2 since IGA2 does contain special hardware for FP.
In this particular case, DVI should be allocated to IGA1.
If the system does not contain an LVDS FP, DVI should be allocated to IGA2 since VGA is typically meant for IGA1.

Created attachment 124206 [details]
Xorg.0.log of V90LE with UMS 0.4.158

hi,kevin
thanks for you explaination,I tried the new verison of openchrome(0.4.158),you can find it in attachment-Xorg.0.log,and I also tried KMS on V90LE,it can work,but I found something weird,the log show as below,you can find it in attachment-Xorg.0.log.V90LEW.KMS.DVI.

    [   149.259] (II) CHROME(0): Output VGA-0 disconnected
    [   149.259] (II) CHROME(0): Output LVDS-0 connected

seems it's probed as LVDS,it confused me.

Created attachment 124207 [details]
Xorg.0.log of V90LE with KMS

FYI

(In reply to frank from comment #11)

Hi Frank,

> Created attachment 124206 [details]
> Xorg.0.log of V90LE with UMS 0.4.158
> 
> hi,kevin
> thanks for you explaination,I tried the new verison of
> openchrome(0.4.158),you can find it in attachment-Xorg.0.log,and I also
> tried KMS on V90LE,it can work,but I found something weird,the log show as
> below,you can find it in attachment-Xorg.0.log.V90LEW.KMS.DVI.
> 
>     [   149.259] (II) CHROME(0): Output VGA-0 disconnected
>     [   149.259] (II) CHROME(0): Output LVDS-0 connected
> 
> seems it's probed as LVDS,it confused me.

You are using the DRM that supports KMS, right?
I think it is the KMS code that is identifying as LVDS-1.
The rumor is that the original code was donated by VIA Technologies, and James Simmons did most of the coding.
My view is that LVDS-x should be renamed PANEL-x and DVI-x should be called DVI-x.
Right now, the OpenChrome UMS code has this type of naming problem, and I plan to fix this down the road.
At this point, I do not plan to fix this at OpenChrome Version 0.5.
Version 0.6 or 0.7 might get the fix.
This naming issue will need to be taken cared fairly soon since RandR is now working (Version 0.4.158 fixed a fatal regression that broke it several years ago.), and multi-monitor feature is now working for the most part.

(In reply to frank from comment #11)

Hi Frank,

> Created attachment 124206 [details]
> Xorg.0.log of V90LE with UMS 0.4.158
> 
> hi,kevin
> thanks for you explaination,I tried the new verison of
> openchrome(0.4.158),you can find it in attachment-Xorg.0.log,and I also
> tried KMS on V90LE,it can work,but I found something weird,the log show as
> below,you can find it in attachment-Xorg.0.log.V90LEW.KMS.DVI.
> 
>     [   149.259] (II) CHROME(0): Output VGA-0 disconnected
>     [   149.259] (II) CHROME(0): Output LVDS-0 connected
> 
> seems it's probed as LVDS,it confused me.

Can you test the runtime screen resize?
I did make a fix to that portion of the code for Version 0.4.158, but all the testing was done on UMS code.
The KMS portion is unproven, and I will like to see how robust the newer screen resize code is.
When you do the testing, please change the screen resolution between a really large screen size and a really small screen size (i.e., 1920 X 1080 down to 640 X 480), and repeat this quasi-randomly between many screen resolutions between 640 X 480 to 1920 X 1080.
If the code is working properly, it should not crash at all.
For the UMS code, the screen resize is now very robust, and I have confirmed that this works perfectly with 5 different VIA chipsets (CLE266, KM400, VN896, VX700, and VX800).

Hi Frank,

I am now primarily working on getting VT1632A to work with VX855 chipset (Wyse C00X).
The Wyse C00X is a thin client, so I am using Puppy Linux 5.7.1 I used several months ago to fix a long running bug of DVI to VGA adapter not working properly (this bug was fixed).
I do not really like Puppy Linux that much, but I have learned to live with it.
Along with that, I am working on a few remaining work that should be put into Version 0.5 before it reaches RC (Release Candidate) status.
So far, I have not figured out why VT1632A is not working.
I do see something coming out of DVI, but the monitor I am using is telling me that it is out of display range.
Very likely, VT1632A DVI support will happen in Version 0.6.

Code to support VT1632A was fixed with Version 0.4.179.
In practice, try Version 0.4.181 or later.
DVI is working with VX855 (Wyse C00X) and I was told, CN700 (Wyse V90LE).
For HP T510's Silicon Image SiI 164, I will try to implement the code when I work on Version 0.6 or 0.7.

Created attachment 125983 [details]
Xorg.0.log - HP T5550 DVI-I rev. 0.5.136

Created attachment 125984 [details]
Xorg.0.log - HP T5550 DVI-D rev. 0.5.136

I've tested the latest current source (0.5.136) on an HP T5550 and have attached two log files with the results. One with a monitor connected to the DVI-I connector and the other with the same monitor connected to the DVI-D connector. In both cases nothing is displayed on the screen. The logs are nearly identical save for things that change on each run; but I've included them both regardless.

(In reply to Justin Chevrier from comment #19)

Hi Justin,

> I've tested the latest current source (0.5.136) on an HP T5550 and have
> attached two log files with the results. One with a monitor connected to the
> DVI-I connector and the other with the same monitor connected to the DVI-D
> connector. In both cases nothing is displayed on the screen. The logs are
> nearly identical save for things that change on each run; but I've included
> them both regardless.

Yeah, it appears that the code is not able to detect the integrated TMDS transmitter for DVI. (likely connected to DVI-D connector)
Since I do not have the actual box in front of me, it is going to be rather hard to figure out how to get it working since the known detection method that worked for my Sylvania g netbook's DVI (integrated TMDS) does not appear to work for your box.
That being said, over the past month, I have rewritten DVI initialization code so that it can support multiple TMDS transmitters (integrated and external) per system.
I was able to create the code to support SiI 164 in about 2 hours since 98% of the code is unchanged from VT1632 support code.
Please try Version 0.5.142 since Version 0.5.141 was a bad commit. (i.e., the files to support SiI 164 were not inserted into the Git repository correctly.)
I do not have a box with SiI 164, so I cannot test the code myself at this point.
I hope it works.

Hi Justin,

Please use Version 0.5.144 or later.
Ones prior to that may have some issues since the code is new and unproven.
I will like to see the Xorg.0.log.
    In terms of what to expect, I will assume that DVI-I is where the DVI should come out.
You will likely have to boot from DVI-I port to see if the code recognizes your DVI.
Please consider this as the first try.
I do not expect the code to work right away, but the important thing for me to want to see is whether or not OpenChrome can detect Silicon Image SiI 164 first.
It should return vendor ID 0001H and device ID 0006H, if it is working correctly.

Created attachment 126035 [details]
Xorg.0.log - HP T5550 DVI-I rev. 0.5.142

Well, for a first pass at the code it sure works well! DVI-I port worked exactly as expected. The log file has been attached. Nice work.

(In reply to Justin Chevrier from comment #22)

Hi Justin,

> Created attachment 126035 [details]
> Xorg.0.log - HP T5550 DVI-I rev. 0.5.142
> 
> Well, for a first pass at the code it sure works well! DVI-I port worked
> exactly as expected. The log file has been attached. Nice work.

Wow, it worked?
That's pretty unusual.
Usually only about 10% of the new code I write work the first try.
Although I try to write quality code as much as I can, there are usually small overlooks that prevent the code from working the first time.
    All I did for this was to change the names of the functions (i.e., VT1632 was changed to SiI164 throughout the code), changed the I2C probing address (10H to 70H), and changed the device and vendor ID being probed. (0001H and 0006H to 1106H and 3192H, respectively)
Okay, I will still need to organize the code a little bit, but the core of the SiI 164 code appears to be working.
Shortly, I will add your name to a commit when I clean up the SiI 164 support code a little bit.
Someone noticed a copyright violation of the original VT1632(A) donated in early 2015, and I was not aware of this until now.
Your name will look like this.

Tested-by: Justin Chevrier <"Justin's e-mail">

Hi Justin,

Regarding the DVI-D connector, I will try to come up with a patch that will disable probing for an integrated TMDS transmitter presence and also not probe for TMDS receiver presence.
VT1632(A) and SiI 164 has hardware that does receiver detection (and works well), but I have really never got this feature to work for the integrated transmitter.
Hopefully, this override patch will at least make the port work.
It might take a day or two to come up with the patch.

Created attachment 126741 [details] [review]
HP T510 DVI-I SiI 164 New Register Settings to Try 1

I changed the register settings of Silicon Image SiI 164 to follow the settings suggested by the datasheet.
I am not sure it will work.
If it works, it will likely replace the older settings that came from VIA Technologies VT1632(A).

Hi Justin,

Can you try the latest code (Version 0.5.159) along with the patch I just uploaded?
For Version 0.5.159, I made changes to the way DVI coming from the integrated TMDS transmitter detects the receiver on the other end.
It is not really too sophisticated, and all I did was to check a different register bit position that supposedly senses DVI presence for the integrated TMDS transmitter.
VIA documentation is not 100% clear on this bit's role, so it might not work correctly.
It appears that VX900 chipset's integrated TMDS transmitter is connected to the DVI-D port, so for the Version 0.5.159 test, please hook up your monitor to the DVI-D port.
    Regarding the patch I just uploaded, it should be applied over Version 0.5.159.
The patch changes Silicon Image SiI 164 TMDS transmitter's register settings.
I am using the "suggested" settings rather than the settings that came from VT1632(A) that worked with Wyse thin clients. (Vx0 and Cx0 models)
Of course, for SiI 164 test, you have to use DVI-I port.
I hope both works.

Hi Justin,

Please disregard the HP T510 name of the patch.
It should work with HP T5550 thin client as well.

Created attachment 126744 [details]
Xorg.0.log - HP T5550 DVI-I rev. 0.5.159 with Sii164 patch

Created attachment 126745 [details]
Xorg.0.log - HP T5550 DVI-D rev. 0.5.159 with Sii164 patch

Hi Kevin,

Thanks for the update! I have updated to 0.5.159 and applied the provided patch. The DVI-I port still works fine, but there's still nothing from the DVI-D port. Logs have been attached to the bug.

(In reply to Justin Chevrier from comment #30)

Hi Justin,

> Hi Kevin,
> 
> Thanks for the update! I have updated to 0.5.159 and applied the provided
> patch. The DVI-I port still works fine, but there's still nothing from the
> DVI-D port. Logs have been attached to the bug.

Thank you for testing the code.
I have rather poor Internet connection situation right now, so my response to you tends to be slow.
I am glad the newer SiI 164 settings work.
I will commit that patch into the repository with your name showing up as the person who tested it.
    As for the integrated TMDS transmitter based DVI, I will make a few more changes to the code.
Basically, the problem is that OpenChrome is not sensing the DVI connected to the integrated TMDS transmitter, hence, it does not let you use DVI-D.
I will need to work on this issue.
I will update the code in the repository soon, and make new patches for you to test against the newer code in the next few days.

Created attachment 126819 [details] [review]
Assume VX900 integrated TMDS transmitter presence patch to try 1

This patch will make OpenChrome assume the availability of a DVI port attached to the integrated TMDS transmitter.

Hi Justin,

I uploaded another patch for you to try.
This one will assume the availability of DVI attached to the VX900's integrated TMDS transmitter.
One of the reason why your DVI coming from the VX900's integrated TMDS transmitter (in this particular implementation, it is attached to the DVI-D port), is due to OpenChrome not being able to properly detect the DVI presence.
For SiI 164 and VT1632(A), there is a way to do this, so OpenChrome knows the availability of the monitor when it inquires the small transmitter chip, but I have had no success with VX900 chipset so far. (or anything other than CX700 / VX700 chipsets)
Over the past few months, I have found several flaws in the existing code, and the flaw was that with the existing code, the software controlled power rail registers shared with laptop type flat panels were only initialized when OpenChrome initializes the laptop type flat panels.
Most thin clients do not come with a laptop type flat panel, so this was a major flaw.
Now, the code initializes the power rail registers in the code dedicated to initializing the integrated TMDS transmitter available in CX700 and VX700 chipsets.
I would imagine that most register locations related to the integrated TMDS transmitters have not changed, so if the code "fakes" the DVI presence, it might be able to control DVI.
I hope it works.

Created attachment 126834 [details]
Xorg.0.log - HP T5550 DVI-D rev. 0.5.160 with assume patch

No change unfortunately; log file attached.

(In reply to Justin Chevrier from comment #34)

Hi Justin,

I have not touched this bug for a while, but it now appears that I will need to backcourt OpenChrome DRM's HDMI code in order to utilize the DVI-D port.
I appears that VX900 chipset's HDMI transmitter is where DVI originates.
HDMI support will likely added to OpenChrome Version 0.7.

> Created attachment 126834 [details]
> Xorg.0.log - HP T5550 DVI-D rev. 0.5.160 with assume patch
> 
> No change unfortunately; log file attached.

-- 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/18.