[Openchrome-devel] [Bug 94863] No signal at VGA (crt-tube) connected to DVI port of VX900

Sun Apr 10 06:14:30 UTC 2016

https://bugs.freedesktop.org/show_bug.cgi?id=94863

--- Comment #17 from Kevin Brace <kevinbrace at gmx.com> ---
(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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/openchrome-devel/attachments/20160410/9a0e7989/attachment.html>