Bug 94863

Hi John,

  I am wondering if HP T5550 and HP T510 is the same type of thin client or not.
  At my side, VGA from DVI-I port for my HP T510 thin client(VX900 based ASIC too which has one DVI-D port and one DVI-I port) is working fine with openchrome latest  0.4.0 UMS driver.
  And I can see correct EDID information in Xorg log. Attached it.

Thanks,
Frank

Created attachment 122801 [details]
HP T510 VGA from DVI-I port Xorg log

I looked at the Xorg.0.log Frank has uploaded.
It appears that in his HP T510 thin client, I2C bus used to obtain EDID (Extended Display Identification Data) is what OpenChrome calls I2C bus 2.
This was the bug I fixed with Bug 91966 (The bug is still open, but hopefully it will close when the original filer confirms the fix. At least I have confirmed the fix with Puppy Linux 5.7.1.).
EDID is used to provide the computer side the monitor's capabilities like screen resolutions it supports.
It has been supported by most monitors since year 1995 or so.
The way OpenChrome is currently written pretty much requires the use of EDID to probe the presence of a VGA monitor (CRT or LCD type does not really matter as long as the interface is VGA).
Yes, OpenChrome does have a last resort backup that will do what I call "manual detection," but I do not believe this ever works.
Perhaps, the code can be removed for now since it does not appear to work (the code has been there for a while).
Justin Chevrier who also owns HP T5550 also uploaded his Xorg.0.log, and his unit was detecting the presence of a VGA monitor via I2C bus 2.

https://bugs.freedesktop.org/attachment.cgi?id=122295
https://bugs.freedesktop.org/attachment.cgi?id=122295&action=edit

Hi John,

I think in terms of developer time attention, your problem will likely get the most attention for a while from here on.
It took a lot of time and effort to release a new version, and I have been taking it easy in terms of coding time for the past 5 days or so.
Also, if your bug is fixed completely, I will likely bump the version to 0.5.0, and urge various Linux / BSD distributions to take the newer version since it solves a serious bug.

Hi John,

I should not throw too many things at once, but several things we will need to consider.

- Does your DVI to VGA adapter work with other computers? (I personally have seen a faulty one at least once in my life.)
- Does straight DVI (native DVI) work? (with a different monitor, of course)
- Does the HP T5550 thin client have a setting in the BIOS setup related to CRT / DVI?


I think we can rule out VGA cable issues since CLE266, CN700, and VX800 chipsets does see the monitor (Model: a770) in question.
This problem appears to be I2C bus related issue since I2C bus 1 and 2 do not see the monitor.
In the case of Frank's HP T510, it does see the VGA monitor via I2C bus.

(In reply to HuangRan from comment #1)
Hi Frank 

T510 seems to me as newer version of T5550. I found below links for them. Both have same I/O ports and very similar (if not same) lspci output. But certainly not same mainboard. 

http://www.parkytowers.me.uk/thin/hp/t510
http://www.parkytowers.me.uk/thin/hp/t5570 (T5570 said to be actually T5550 w/ Windows Embedded)

As I mentioned on my reply to your message at bug 91966, what I wonder is if anybody else tested 0.4.0 with crt monitor. AFAIK, Justin Chevrier also owns a T5550 and sent xorg.log files for successful tests of VGA connected to DVI but I think he is also testing it with LCD. 

John

(In reply to Kevin Brace from comment #5)

Hi Kevin 

Thanks for your comments. I totally agree with you on eliminating other possible causes of failure. But the thing is, same T5550, DVI-VGA adapter and crt monitor setup works with via-opensource driver. I am just changing my driver and rebooting. Two log files "Xorg.0.log-via-opensource-VX900-crt" and "Xorg.0.log-openchrome-4.0.0-VX900-crt" in my attachment comes from just same HW setup. My life experience says that even this can not totally eliminate possibilty of HW failure or other casues of problem but it seems less likely. I wish Frank or Justin can test it with a crt. 

Regarding other questions, I have tested DVI-VGA adapters with other devices. I did not test direct DVI monitor connection to T5550 as I do not have one to play with at the moment. And no, unfortunately there is nothing in BIOS of T5550 regarding display device connection, its totally ignorant on this. 

Lastly, do you see any possibilty in the driver side to (re)implement a fallback setup if no monitor detected. What I mean is, acting as if there is a VGA monitor detected at DVI-I port supporting (some ?) standart VESA modes. I do not know if it is possible or worth to work on but just my two cents. 

John

(In reply to John Friend from comment #7)
> (In reply to Kevin Brace from comment #5)
> 
> Hi Kevin 
> 
> Thanks for your comments. I totally agree with you on eliminating other
> possible causes of failure. But the thing is, same T5550, DVI-VGA adapter
> and crt monitor setup works with via-opensource driver. I am just changing
> my driver and rebooting. Two log files "Xorg.0.log-via-opensource-VX900-crt"
> and "Xorg.0.log-openchrome-4.0.0-VX900-crt" in my attachment comes from just
> same HW setup. My life experience says that even this can not totally
> eliminate possibilty of HW failure or other casues of problem but it seems
> less likely. I wish Frank or Justin can test it with a crt. 
> ...

I think I may have a CRT or two laying around that I could try. I won't have access to them until next week, but if no headway is made by then I'd be happy to give it a go.

Hi John,

I will reply to your message maybe tomorrow, but looking at the 2 logs you have attached for VX900 chipset, I must say that there seems to be something weird about your particular unit.
This is because let's assume that OpenChrome is buggy, but VIA Technologies in house device driver is working properly.
I2C bus is typically used as the first option for display detection, including VGA monitors (CRT or LCD does not really matter).
When I read VIA Technologies in house device driver log, it appears that it is also not seeing your VGA monitor via I2C bus, hence, it is resorting to the use of what you called a "fake" monitor information.
Actually, this type of situation does happen, and I recently had another person file a bug report similar to your situation (Bug 94277).
Personally, it will be nice if you can attach a different monitor with VGA interface to this unit to see what it does.
Regarding the monitor type, CRT or LCD does not matter to OpenChrome since EDID that comes from any VGA interface will always identify as an analog type interface (and this also assumes that it is working properly in the first place), and this is used by other Linux device drivers to detect a VGA interface as well.
If you are able to borrow another monitor (CRT or LCD) with a VGA interface, you may want to attach that to see if OpenChrome will recognize the monitor or not.
If not, I think there is a high probability that there is a problem with the unit.
Another possibility can be hardware level incompatibility, but I will not want to go there for now.
I do know people do think that OpenChrome is suspect, and that is not a bad assumption considering that bugs have multiplied over the years without much repairs being done until now.
However, even the better quality VIA device driver (They do have in house help in writing the device driver from the hardware design side. That's a huge advantage they have over the previous OpenChrome developers and me.) is not detecting your VGA monitor, and I find that concerning.

(In reply to Kevin Brace from comment #9)

> However, even the better quality VIA device driver [...] is
> not detecting your VGA monitor, and I find that concerning.

Yes, but that is a fact of life: there is so much crappy and deficient hardware out there -- not having an EDID, not responding to any kind of polling, simply undetectable.  /But/... they work perfectly well when fed with the right input.

So, defaulting to VGA when nothing can be detected would be nice.  And allowing the user to override this with an xorg.conf option telling the driver that there /is/ a VGA/DVI/XXX device connected even if it can't be detected, would be even better.  Detection is beautiful, but it simply won't work for all devices.

Hi John,

  Yup, it seems T510 is relative newer than T5550 with your links. Yesterday, I have purchased two sets of T5550 thin clients. After I receive it in next few days, I can give a test to help you verify at my side if this issue has not been solved yet at that time. And then, I can give a debug to see what happens.
  I went through this thread including what Kevin and Benno talked about below, my opinion is that besides Justin helped you try a crt monitor next week, you can give a try with another CRT/LCD monitor with a VGA port on your T5550 platform as Kevin suggested if that is possible. That can narrow down where the root cause is. Actually Kevin is correct, whatever it is a CRT or LCD monitor, the EDID information should be probed out by the same I2C bus(i.e, i2c bus2) if you are using the same board. And in general, the graphics driver will use this EDID information to generate several modelines for users to choose(sometimes, modeline prune will be done before real mode setting is happening, i.e., in KMS driver).

Hi Kevin,

   I also suggested to add some code as Friend/Benno suggested if the EDID probe is failed for some uncertain reason like this. As I have done before, if there is no EDID probed out, the user can use a xorg.conf or a registry file(like Windows CE) to add a mode which the user wants to support, and then the graphics driver can use this mode to do the mode setting and make everything work. At least, it can make the graphics mode work although it is not using detected EDID information and will not frustrate users if the monitor is black and shows nothing on that.

Thanks,
Frank


(In reply to John Friend from comment #6)
> (In reply to HuangRan from comment #1)
> Hi Frank 
> 
> T510 seems to me as newer version of T5550. I found below links for them.
> Both have same I/O ports and very similar (if not same) lspci output. But
> certainly not same mainboard. 
> 
> http://www.parkytowers.me.uk/thin/hp/t510
> http://www.parkytowers.me.uk/thin/hp/t5570 (T5570 said to be actually T5550
> w/ Windows Embedded)
> 
> As I mentioned on my reply to your message at bug 91966, what I wonder is if
> anybody else tested 0.4.0 with crt monitor. AFAIK, Justin Chevrier also owns
> a T5550 and sent xorg.log files for successful tests of VGA connected to DVI
> but I think he is also testing it with LCD. 
> 
> John

By the way, Friend, the "via-opensource driver" you mentioned is VIA's closed driver(DRM code is open source) which can be downloaded from via's website? I want to know exactly what "via-opensource driver" you are using.

Thanks,
Frank

(In reply to HuangRan from comment #12)

Hi Frank 

via-opensource driver I used is a bit never version of semi-opensource KMS driver available at via web site. You can check it at below link. I got this link from thinstation project. 
http://manu.agat.net/5.76.52.92-opensource-009-005f78-20150730.tar.gz

Pls. see my next comment regarding other issues you have mentioned. 

John

(In reply to Kevin Brace from comment #9)

Hi Kevin,

I have already tested two different crt monitors with two different DVI-VGA adapters. Please also note that very same monitor supplies EDID data to same openchrome-0.4.0 driver when connected to VGA port of CLE266/CN700/VX800 devices as seen on my previous logs. Yet I have tested a third monitor today (Philips 107E) on T5540(VX800) and T5550(VX900) and I will send the logs shortly. 

I understand that CRT and LCD are same regarding detection. Then maybe LCD monitors behave better on providing EDID data simply because they are never products than CRT monitors. 

I have also tried applying a patch to openchrome-0.4.0 just like Benno did previously at Bug 94277 and I am able to get image on same VGA moitor connected to DVI port of T5550. Sure its not getting any EDID data by this way, but blindly setting some modes as via-opensource driver did. I will send the patch and log files shortly.

What I understand so far is, there is some shortcomings in getting EDID data from (some) VGA devices connected to DVI port of VX900 (or maybe any DVI port in general). So, IMHO, it may be better to implement a mechanism to fallback to default modes and let the user set other modes in xorg.conf rather than trying to get EDID data from any and all monitors. At this point, it will be a good practice to support as much resolutions as possible in fallback. Because although one of my monitors (not the ones I have sent the logs) supports 1600x1200, I can get upto 1280x1024 by via-opensource driver and upto 1024x768 by modified openchrome-0.4.0 driver as they provide only upto these resolutions. 

John

Created attachment 122839 [details]
xorg.log files of Openchrome 0.4.0 (VX900, VX800) and via-opensource (VX900) tests w/ Philips 107E CRT monitor

Created attachment 122840 [details]
xorg.log and patch againts openchrome-0.4.0 to forcely detect VGA monitor connected to DVI port of T5550 (VX900)

(In reply to John Friend from comment #14)

Hi John,

> 
> Hi Kevin,
> 
> I have already tested two different crt monitors with two different DVI-VGA
> adapters. Please also note that very same monitor supplies EDID data to same
> openchrome-0.4.0 driver when connected to VGA port of CLE266/CN700/VX800
> devices as seen on my previous logs. Yet I have tested a third monitor today
> (Philips 107E) on T5540(VX800) and T5550(VX900) and I will send the logs
> shortly. 
> 
> I understand that CRT and LCD are same regarding detection. Then maybe LCD
> monitors behave better on providing EDID data simply because they are never
> products than CRT monitors. 
> 

Okay, we can rule out DVI to VGA adapter.
This appears to be a possible defective unit or specifically I2C bus 1 and 2 are disabled for this model.
Again, CRT or LCD does not matter as long as the interface is VGA.
The code to detect a VGA monitor basically runs through the same code path regardless of the chipset.
Which means VX900 chipset is going through the same code path CLE266, CN700, and VX800 chipsets go through.
There is always a possibility of OpenChrome assuming that certain registers are initialized prior to the loading of the device driver, and I had someone else report this possibility just recently (Bug 94797).
I only gained commit privilege 2 months ago, and I have not had the time to rewrite the initialization code.
Previous developers left behind too many problems in the code, and I am merely during clean up / QA related work for now.
It will likely be like this for the foreseeable future.


> I have also tried applying a patch to openchrome-0.4.0 just like Benno did
> previously at Bug 94277 and I am able to get image on same VGA moitor
> connected to DVI port of T5550. Sure its not getting any EDID data by this
> way, but blindly setting some modes as via-opensource driver did. I will
> send the patch and log files shortly.
> 

One reason why I am trying to figure out if the unit has a problem, is to avoid "false negative" type of situation.
It is easy to assume that OpenChrome is buggy, and again, this is not a bad assumption considering the code neglect the project has gone through over the past few years.
However, I have spent disproportionate amount of time on fixing DVI to VGA adapter monitor detection regression (Bug 91966), so at least I have some understanding of how OpenChrome code works than 5 months ago.
I only have finite amount of time to fix bugs considering the dozen of bugs known by me alone, and based on this, I really need to be careful not to waste my time on "false negative" type of situation.
This is why I have not admitted that this is an OpenChrome related problem, and is probably a unit problem since two monitors appear to have similar outcomes (neither or them are detected by OpenChrome).


> What I understand so far is, there is some shortcomings in getting EDID data
> from (some) VGA devices connected to DVI port of VX900 (or maybe any DVI
> port in general). So, IMHO, it may be better to implement a mechanism to
> fallback to default modes and let the user set other modes in xorg.conf
> rather than trying to get EDID data from any and all monitors. At this
> point, it will be a good practice to support as much resolutions as possible
> in fallback. Because although one of my monitors (not the ones I have sent
> the logs) supports 1600x1200, I can get upto 1280x1024 by via-opensource
> driver and upto 1024x768 by modified openchrome-0.4.0 driver as they provide
> only upto these resolutions. 
> 
> John

I can consider adding default recognition of a VGA monitor using a method I used to detect LCD recently.
If this were to be added, it will likely be the next version after the next one I hope to release in the next 2 weeks.
Basically, fixing one major bug alone warrants a new release at this point, and the code addition of this feature will be done at that time.
    In general, I am philosophically against manual modes, and this is the mistake OpenChrome made 11 years ago when they had a nasty schism with UniChrome.
The addiction to manual mode is what led to that monster called "known device table" that I had to get rid of it with Version 0.4.0 because previous developers did not want to.
Even Xavier Bachelot who was one of the people who split from UniChrome finally admitted to me that maintaining the "known device table" became impossible task to handle since even the lowly VIA Technologies can easily have more than 10 customers per chipset (some of them had 40+ models per chipset), and it is impossible to get users to report every possible VIA silicon device in the world to fill this table (not to mention the waste of memory for holding this table).
This is why I got rid of this ridiculous table, and at the same time, I got rid of other xorg.conf options that were not desirable to have in year 2016 (or for that matter year 2010) level graphics device driver.
    I know I may have sounded somewhat combative in what I just wrote, but personally, I do not want to be blamed for not supporting CRT based VGA monitors since I have done some testing with them (CN896 chipset and K8M800 chipset) and I do not have a VX900 chipset based unit with VGA coming out.
It is not realistic to expect me to own every VIA silicon hardware.
The OpenChrome Version 0.4.0 has gone through a lot of testing by me and volunteers (i.e., people who compiled the master branch code) prior to release, and as far as I am concerned, most people are reporting good results based on the experience people already had with it.
This is with myself taking out known device table and several other legacy manual modes later in the release cycle (a fairly large risk I ended up taking).
John, I am sorry that you are having issues, and I am not able to fix the problem right away.
It is very difficult to fix any bugs OpenChrome still contains since I only assumed the position of fixing the code recently (2 months), and even today, OpenChrome code is still in a very bad shape, especially the display detection portion I am devoting a lot of my personal time.

Hi John,

I will likely put default recognition of a VGA monitor feature into OpenChrome Version 0.5.0.
That being said, I am still very much against manual settings as a general rule, so the screen resolution may have to be limited to 800 X 600 and 640 X 480 (Microsoft Windows did something like this for their safe mode in Windows 2000.) for monitors the device driver was not able to read its EDID (i.e., pre-VESA DDC monitors and ).
In general, I am going in the direction of removing manual settings, and removed several manual settings for Version 0.4.0.
I will likely remove a few more for Version 0.5.0.
    It is hard to say how long the next version of OpenChrome will take.
At this point, I will like to spend a few months fixing problems, and one of the issue that needs to be dealt with is how the display output is assigned to which display controller.
Because of the unhealthy reliance on the "known device table" by the previous developers, I do not believe OpenChrome is capable at this point to dynamically allocate the appropriate display controller based on the detected output display resources.
Display resources have to be assessed before appropriate display controller is assigned since the 2 display controllers are not symmetrical (they are asymmetrical).
This is in addition to the code cleanup I am conducting right now.
    I could incorporate the temporary fix you performed into the code if that is what you want for now, but in general, the supported screen resolution should be rather low.
I do have certain approaches to issues, and as you can tell, I do not particularly like manual settings (however, I will not try to get rid of all of them, either).
However, they are sometimes necessary, and I tend to think of something like this to be akin to a "limp mode" in automobiles.
As far as I am concerned, what you and Benno are asking is a "limp mode," and I do not mind having it as long as the scope is limited (i.e., limited screen resolution).

(In reply to Kevin Brace from comment #18)
> so the screen resolution may have to be limited to 800 X 600 and 640 X
> 480 [...] for monitors the device driver was not able to read its EDID

That is ridiculous.  My monitor does not /have/ an EDID, so it /cannot/ be detected, but it is perfectly able to show 1280x1024, and openchrome is able to provide that mode when it is told to generate it and that a monitor is there.

What you are proposing is to /willingly/ cripple devices that can work flawlessly if you allow users to provide the data that the driver can't detect.

It is not a "limp mode", it is a "drive-blind mode" -- trust the user, give him the wheel, and the clutch, and the accelerator.

Hi John,

  Okay, actually this driver is what I am now investigating with(compared to current drm-openchrome KMS driver). But mine is a little different from yours because mine only has source code files to compile via_chrome9.ko which is under TTM folder. For other tow user drivers(via_drv.so and via_chrome9_dri.so), there is no source files to compile them. 
  Then, I did further check on the website: 
   http://linux.via.com.tw/support/downloadFiles.action
  Finally I found the same driver as yours under this link when I select "Lubuntu 15.04" as the OS and "VX900" as the platform. The driver includes not only via_chrome9.ko source files, but also via_drv.so source files.
  Actually I have used this via open source driver verified VGA port on my T510 platform and see it can make VGA work properly and EDID information can be probed out(not fake EDID information). Again, I am using a LCD monitor instead of a CRT monitor.
  If you can wait for several days until my HP T5550 come, I think I can provide you more help on this issue.

Thanks,
Frank
  

(In reply to John Friend from comment #13)
> (In reply to HuangRan from comment #12)
> 
> Hi Frank 
> 
> via-opensource driver I used is a bit never version of semi-opensource KMS
> driver available at via web site. You can check it at below link. I got this
> link from thinstation project. 
> http://manu.agat.net/5.76.52.92-opensource-009-005f78-20150730.tar.gz
> 
> Pls. see my next comment regarding other issues you have mentioned. 
> 
> John

(In reply to Benno Schulenberg from comment #19)
> (In reply to Kevin Brace from comment #18)
> > so the screen resolution may have to be limited to 800 X 600 and 640 X
> > 480 [...] for monitors the device driver was not able to read its EDID
> 
> That is ridiculous.  My monitor does not /have/ an EDID, so it /cannot/ be
> detected, but it is perfectly able to show 1280x1024, and openchrome is able
> to provide that mode when it is told to generate it and that a monitor is
> there.
> 
> What you are proposing is to /willingly/ cripple devices that can work
> flawlessly if you allow users to provide the data that the driver can't
> detect.
> 
> It is not a "limp mode", it is a "drive-blind mode" -- trust the user, give
> him the wheel, and the clutch, and the accelerator.

Agree with Benno on this point...
We should give the user privilege to set the mode they want when no edid information can be probed out by the driver.


Thanks,
Frank

(In reply to Kevin Brace from comment #18)

Hi Kevin

Thanks for your reply. I appreciate your efforts and understand that you are working on several issues including mine. Please feel free to give a lover priority to my issue. Because although I would higly prefer to use fully opensource openchrome driver, currently I am good with via-opensource driver. Actually my primary motive on filing this bug and testing recent openchrome driver on several different VIA hardware is just helping you and other people spending their valuable time to make it better. 

I have copied the patch from Benno's and applied to 0.4.0 just hoping that it will helpfull to you. Its useless for me as it provides very limited resolutions and its impossible to set more resolutions/modelines in xorg.conf.

I agree that "known device table" is a bad idea. But I do not know if it is necessary for a fallback ? 

In my opinnion, xorg.conf setup is not that bad. Its necessary not only for cases where auto detection fails, but also its a freedom for user. What if I do not want to rely on EDID data and like to have a fixed resolution for an embedded device. What if I have a KVM device or another converter preventing EDID data to pass. I think many modern and bleeding edge drivers still keep  these options not only in xorg.conf, but also provide them as module parameters (for KMS drivers). 

Please do not take my words as a criticism on your ideas or blaming openchrome on doing that or not doing this. I am just trying to give some feedback resulting from several years of experience on user issues. As Benno previous stated on another thread, you are the coder, just state how you will do it and its the law : )

(In reply to HuangRan from comment #20)

Hi Frank

Thanks for your attention. Please take yor time and let me know when you have something new to test. No urgency on my side. 

John

(In reply to John Friend from comment #23)

Hi John,

> (In reply to HuangRan from comment #20)
> 
> Hi Frank
> 
> Thanks for your attention. Please take yor time and let me know when you
> have something new to test. No urgency on my side. 
> 
> John

I am glad you are not in a rush.
I sometimes disappear for a few days to concentrate on getting something done, so myself not responding to your e-mail for several days is fairly normal for me.
I reduced my hours I work on OpenChrome for the past few days, and I must say that I do have to take a breather from time to time.
    I must say that I experimented with the idea of assuming the detection of a VGA monitor (I will call it default detection.) proposed by Benno Schulenberg on Sunday for a few hours, and based on the results I saw, I do not really like the idea at this point.
The computer I tested this set up was Sylvania gnet 13001 netbook.
It comes with a small 800 X 480 (7") flat panel and a DVI-I connector.
When I boot the computer without a VGA monitor to this netbook, it will detect a VGA monitor and the FP.
The problem is, with OSes like Lubuntu that put their taskbar (i.e., something similar to Microsoft Windows taskbar where the default start button and the current running programs are displayed) at the bottom, the OS becomes effectively inoperable since Lubuntu adjusts the location of the taskbar against the higher resolution screen.
In this particular experiment, it automatically assigned the VGA monitor 800 X 600 screen resolution, and when the X server starts, it starts with in clone mode.
What ends up with this configuration is that the taskbar gets adjusted against the higher resolution VGA monitor, and from the small 800 X 480 flat panel screen, the mouse cursor cannot reach the taskbar.
Hence, effectively the computer is inoperable without a VGA monitor, and as I have already mentioned that this is a netbook (portable equipment).
    I thought about this issue for a day or so (I am glad I did.), and this idea, at least to me, is acceptable (it is fundamentally similar to Benno's idea).
At this point, OpenChrome is not written in a way to assess the display devices connected beforehand.
This is probably historical since it used to rely on the "known device table" I already have discussed until very recently.
The way it assigns the display resources is that it individually detects and registers the display resources.
They do this for VGA, TV, LVDS / DVI (integrated type), and DVI (external type; currently disabled).
The big problem with this approach is that it does not have the ability to get to analyze the available display resources before they are registered.
VIA IGPs have asymmetrical display controllers (they call it IGA1 and IGA2), and there are situations where the certain display resources need to be routed to the other IGA since IGA1 and IGA2 have different functionality.
IGA2 is really meant for LVDS FPs since it contains special hardware for FPs.
IGA1 is really meant for VGA type classical CRTC (CRT Controller) with no special hardware for FPs.
The problem with this arrangement is, what do I do when I want to connect a DVI monitor to the computer?
Depending on the situation, DVI needs to be routed to either IGA1 or IGA2, and DVI really can be utilized by either IGA.
However, FP always need to be routed to IGA2 and VGA almost always go to IGA1.
    What I am describing here might sound something beyond the bug you are reporting.
That might be true, but once I rewrite the code to improve the display detection algorithm (I was already planning to do this anyway.), I can easily implement a feature like reporting a "fake" VGA monitor detection to the X server if no display resources were detected.
This is because OpenChrome will know beforehand prior to the X server doing the actual display detection that which display resources is available, and this will obviously include a situation where it was not able to find any display devices connected to the computer.
If there are no display devices connected to the computer, I can definitely say that it is relatively harmless to lie to the X server that there is a VGA monitor connected to the computer even if OpenChrome is not really able to detect it via I2C bus.
If the DDX (Device Dependent X) device driver does not lie to the X server about monitor detection, X server will refuse to start (a situation I am sure you have observed), I feel like it is okay to lie to it if no display was detected.
This idea of lying to the X server while being all automatic detection, I do not feel like violates my view that display detection should be as automatic as possible since we are living in year 2016 (this is not '90s or mid-2000 X server), and computer devices should be as easy as possible to set it up.
    The developer who "still" develops ATI r128 (Rage 128) DDX recently added this feature (default VGA detection) to his device driver (Other than the "Big 3" of Linux x86 platform graphics, only OpenChrome and r128 are still maintained by someone.) since he encountered similar issues.

https://cgit.freedesktop.org/xorg/driver/xf86-video-r128/commit/?id=562681414f38c6925da01b3fec0802f532cd9e53

Of course, the situation is much worse with VIA Chrome family of IGP in many ways since Rage 128 was a short lived family that existed between Rage Pro and Radeon (it was their mainstream chip for only 3 years between 1998 to 2000), but VIA IGP had 8 to 10 chipset generations with many different external transmitter / encoder combinations that lasted from 2003 (CLE266) all the way to 2009 (VX900), and VX900 is still available (since most of users that still want them use it for embedded applications).
    I am in the process of cleaning up the code, and the purpose of this is to figure out how the current code works.
Once I finish implementing the improved display detection algorithm, it will be fairly easy to add "default detection" of VGA while still being fully automatic detection.
Unfortunately, this will limit the screen resolution to what the X server provides you, so fundamentally, this may have the same outcome you have today.
The real purpose of improving the display detection algorithm is really to support DVI better since the DVI support is really broken at this point, and complete rewriting is necessary to properly support DVI as well as future plan to fix standby mode resume reliability.

(In reply to John Friend from comment #23)
> (In reply to HuangRan from comment #20)
> 
> Hi Frank
> 
> Thanks for your attention. Please take yor time and let me know when you
> have something new to test. No urgency on my side. 
> 
> John

Hi John,

  My HP T5550 arrives just now. It looks very similar as T510, but something different for the shape and configuration. I can give a try and let you know the result soon for VGA port from DVI-I.

Thanks,
Frank

Hi John,

  After my test on T5550, VGA from DVI-I port is working fine with my LCD monitor. Attached is Xorg.log.

  T5550: CPU is Nano, 1G memory
  T510: CPU is Eden, 2G memory

Created attachment 122929 [details]
HP T5550 VGA from DVI-I port Xorg log

(In reply to HuangRan from comment #26)

Hi Frank
Thanks for info. Do you have any CRT around to test ?

Hi Frank,

There is a possible regression of an integrated TMDS transmitter (DVI) support with CX700, VX700, and VX900 chipsets.
I will try to analyze why the regression happened, but if you wanted to test the DVI of VX900 chipset, that will be helpful.

Hi Frank and John,

I do not want to float a weird idea, but can this be BIOS revision related issue?
Is there a way to check the BIOS revision when the thin client boots?
Also, I was thinking of running the VIA VGA register dump tool to check the I2C bus status.
It is always possible that certain registers are being turned off when booting, and OpenChrome is relying on someone else setting them up correctly for I2C bus to work.
As far as I am concerned, OpenChrome should initialize every relevant I2C related registers on its own.

Hi Frank,

At least I am glad that VGA is working via DVI to VGA adapter.
If Justin Chevrier can also test his unit, that will further confirm that this regression bug was fixed from Version 0.2.904.

(In reply to John Friend from comment #28)
> (In reply to HuangRan from comment #26)
> 
> Hi Frank
> Thanks for info. Do you have any CRT around to test ?

Hi John,

   Currently at hand, there is no CRT monitor. I have to see if I can find one. CRT monitor is too old to find.


Thanks,
Frank

(In reply to Kevin Brace from comment #29)
> Hi Frank,
> 
> There is a possible regression of an integrated TMDS transmitter (DVI)
> support with CX700, VX700, and VX900 chipsets.
> I will try to analyze why the regression happened, but if you wanted to test
> the DVI of VX900 chipset, that will be helpful.

Sure, Kevin. What do you want me to test on VX900 platform with DVI port?

Thanks,
Frank

Created attachment 122955 [details]
T5550 BIOS version

Created attachment 122956 [details]
T5550 Configuration

(In reply to Kevin Brace from comment #30)
> Hi Frank and John,
> 
> I do not want to float a weird idea, but can this be BIOS revision related
> issue?
> Is there a way to check the BIOS revision when the thin client boots?
> Also, I was thinking of running the VIA VGA register dump tool to check the
> I2C bus status.
> It is always possible that certain registers are being turned off when
> booting, and OpenChrome is relying on someone else setting them up correctly
> for I2C bus to work.
> As far as I am concerned, OpenChrome should initialize every relevant I2C
> related registers on its own.

I think it is one possible reason. But for VGA port, I do believe if you can see the BIOS screen when boot up, actually the BIOS has initialized VGA related registers. And Openchrome should successfully do mode setting for VGA port.


Thanks,
Frank

Created attachment 122965 [details]
VGA SEQ/CRT dump registers

Hi John/Kevin,

  I am sorry that I can't find a CRT monitor at my hand after searching it for a whole day.
  But we provided you the VGA SEQ/CRT register dump result with DDX tool for your reference.

Thanks,
Frank

(In reply to HuangRan from comment #38)
Hi Frank 
Thanks anyway. Also thanks for info provided. 

Hi Kevin 
I will check and post the BIOS version info hopefully by tomorrow as at the moment I am not at the place where the device is. 

And now I am more curious about Justin's test with crt connected to T5550

John

Created attachment 122977 [details]
T5550 VGA on the DVI-I port with Viewsonic G225f CRT

Here's the log with a Viewsonic G225f CRT attached to an HP T5550 using DVI-I to VGA adapter. Monitor worked without issue.

(In reply to HuangRan from comment #33)

Hi Frank,

> (In reply to Kevin Brace from comment #29)
> > Hi Frank,
> > 
> > There is a possible regression of an integrated TMDS transmitter (DVI)
> > support with CX700, VX700, and VX900 chipsets.
> > I will try to analyze why the regression happened, but if you wanted to test
> > the DVI of VX900 chipset, that will be helpful.
> 
> Sure, Kevin. What do you want me to test on VX900 platform with DVI port?
> 
> Thanks,
> Frank

I will correct myself that at least for VX700 chipset, DVI is still working.
It will be nice if you can try out with your unit since I believe has similar hardware.

(In reply to Justin Chevrier from comment #40)

Hi Justin,

> Created attachment 122977 [details]
> T5550 VGA on the DVI-I port with Viewsonic G225f CRT
> 
> Here's the log with a Viewsonic G225f CRT attached to an HP T5550 using
> DVI-I to VGA adapter. Monitor worked without issue.

Can you also try out DVI coming out from the DVI-I connector?

(In reply to Justin Chevrier from comment #40)
> Created attachment 122977 [details]
> T5550 VGA on the DVI-I port with Viewsonic G225f CRT
> 
> Here's the log with a Viewsonic G225f CRT attached to an HP T5550 using
> DVI-I to VGA adapter. Monitor worked without issue.

Thanks for the test. I will post if I can find anything new regarding why its not working on my side. However, in my opinnion, this experiment shows that there may always be cases where EDID data can not be obtained, while its very well possible to make it work without it. 

John

Hi Kevin,

(In reply to Kevin Brace from comment #41)
> I will correct myself that at least for VX700 chipset, DVI is still working.
> It will be nice if you can try out with your unit since I believe has
> similar hardware.

  We are now trying to make a matrix table to collect all DVI interface status for the thin clients at my hand.
  I believe that will be very helpful for further work on DVI interface.

Thanks,
Frank

Hi John, 

   Sorry that I put more information on DVI test result here which is not related to  this VGA(crt-tube) issue.


Hi Kevin,

   We give a test with OpenChrome UMS 0.4.0 driver on T510/T5555/C90LE/V90LE thin clients for DVI-I and DVI-D ports(C90LE and V90LE do not have DVI-D port) and get following results:

                 DVI-I            DVI-D
T510              fail             suc
T5555             fail             suc
C90LE             fail              X 
V90LE             suc               X

   From the result we tested, it shows for DVI-D port for T510/T5555, the UMS driver is working fine; By contrast, for T510/T5555 DVI-I port, the UMS driver is failed to work. The possible reason is that DVI-I uses a external TMDS transmitter Silicon Image Sil164 which current UMS driver does not support.
   For V90LE and C90LE, the result is very interesting because they both uses VT1632 as the external TMDS transmitter, but the result is totally different.

Thanks,
Frank

Hi Kevin,

  I suggest we open another thread to discuss DVI interface issue to avoid the confliction with current John's thread for VGA port.

Thanks,
Frank

(In reply to HuangRan from comment #45)
> Hi John, 
> 
>    Sorry that I put more information on DVI test result here which is not
> related to  this VGA(crt-tube) issue.
> 
> 
> Hi Kevin,
> 
>    We give a test with OpenChrome UMS 0.4.0 driver on T510/T5555/C90LE/V90LE
> thin clients for DVI-I and DVI-D ports(C90LE and V90LE do not have DVI-D
> port) and get following results:
> 
>                  DVI-I            DVI-D
> T510              fail             suc
> T5555             fail             suc
> C90LE             fail              X 
> V90LE             suc               X
> 
>    From the result we tested, it shows for DVI-D port for T510/T5555, the
> UMS driver is working fine; By contrast, for T510/T5555 DVI-I port, the UMS
> driver is failed to work. The possible reason is that DVI-I uses a external
> TMDS transmitter Silicon Image Sil164 which current UMS driver does not
> support.
>    For V90LE and C90LE, the result is very interesting because they both
> uses VT1632 as the external TMDS transmitter, but the result is totally
> different.
> 
> Thanks,
> Frank

(In reply to HuangRan from comment #45)

Hi Frank 

Not personally offensive for me but it will be much easier for develeopers and everybody else in future to track whats going on if a new bug submitted.

John

> Hi John, 
> 
>    Sorry that I put more information on DVI test result here which is not
> related to  this VGA(crt-tube) issue.
> 
>

Hi John,

   Yup, I have created another thread to track it and discuss DVI issue there now.
   https://bugs.freedesktop.org/show_bug.cgi?id=95059.

Thanks,
Frank

(In reply to John Friend from comment #47)
> (In reply to HuangRan from comment #45)
> 
> Hi Frank 
> 
> Not personally offensive for me but it will be much easier for develeopers
> and everybody else in future to track whats going on if a new bug submitted.
> 
> John
> 
> > Hi John, 
> > 
> >    Sorry that I put more information on DVI test result here which is not
> > related to  this VGA(crt-tube) issue.
> > 
> >

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