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

Wed Apr 13 03:48:21 UTC 2016

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

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

-- 
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/20160413/993342a4/attachment-0001.html>