[Openchrome-devel] [Bug 91966] No signal to monitor with X and openchrome using VX855 chipset graphics

Thu Apr 7 21:20:54 UTC 2016

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

--- Comment #323 from Kevin Brace <kevinbrace at gmx.com> ---
(In reply to Christopher from comment #319)

Hi Christopher,

> @ Jeffrey -- I've been proactive. I've been sidelined --only recently-- by
> an issue related tangentially to this bug (install issues), and I'm working
> actively with a member of the Puppy community to fix that. It's just not
> fixed yet.
> 

Yes, I strongly recommend that Puppy Linux incorporate OpenChrome Version 0.4.0
with Puppy Linux 5.7.1 (precise puppy) and 6.0.5 (tahrpup).
If they still maintain it, they should also replace the OpenChrome that came
with Ubuntu 10.04 LTS based Puppy Linux as well.
OpenChrome Version 0.4.0 works fine with Ubuntu 10.04 LTS except Lubuntu 10.04
and CLE266, KM400, KM400A, KN400, and P4M800 (software cursor display bug).

> @ Kevin --
> 
> I'm still confused, at least a little bit. I'm not blaming you for anything
> at this point -- indeed, I'm very thankful for all you've done for me --
> except for this one somewhat frustrating bit of not doing what I've asked to
> confirm whether it is indeed my environment or not. You insist -- but you
> will not offer proof. I understand that you are frustrated. I can relate!
> But I still need to know whether or not it's the environment for certain --
> and until that is tested, all we have is speculation and assumption.
> 

If I have to, I can present proof that the OpenChrome Version 0.4.0 works with
Puppy Linux 5.7.1.
The "proof" was originally done for a pre-release version of OpenChrome Version
0.4.0, but I can retest it with OpenChrome Version 0.4.99 (I altered the
version update policy within the past 24 hours.)
I can upload the Xorg.0.log if I have to, and I probably have to spend time on
this.
I will explain to you shortly, but please remember that I have other bugs I
have to fix other than your bug.

> You've tested it on a different OS and a different chipset, and it works.
> That's great. That's amazing. That's wonderful.
> 
> But it's not my OS and it's not my hardware.
> 

Yes, but from my own experience of being a developer for OpenChrome for several
months already, to some extent, VIA Technologies IGP (Integrated Graphics
Processor) display controller and 2D accelerator hardware apparently do not
change that much from chipset to chipset.
That makes sense; while people do not think very highly of their IGPs, it is
still a very complex piece of digital hardware (i.e., multi-million gate ASIC,
especially Chrome9).
There is a fair amount of continuity in their designs (this is called "design
reuse" in the ASIC design community), hence, if things work with one version,
there is a good chance it will work with another close generation one.

> I'm using a TahrPup 6.0.2 based Pup, not Tahr 6.0.5. I'm using the VX855
> chipset, not CN896.
> 

P4M900 / VN896 / CN896 are apparently all related and VIA publicly called the
IGP inside Chrome9 HC.
I do not know what HC stands for.
Chrome9 is supposedly a modern IGP that can obtain Windows Vista Basic logo
from Microsoft (i.e., a marketing prerequisite for selling the chipset to PC
and mainboard vendors since 2007).
VX800 is a second product in the family of highly integrated chipset where
traditional northbridge (CPU interface, memory controller, AGP / PCI Express
controller, etc.) and southbridge (PCI, PCI Express, USB, PATA, SATA, ACPI,
etc.) were integrated together along with a Chrome9 based IGP.
The IGP inside VX800 was called Chrome9 HC3.
Looking at the documents VIA has made public, it appears that VX855 is
primarily an upgrade to their video playback engine compared to VX800 (i.e.,
H.264 support).
What I am trying to say here is that, while CN896 and VX855 seem unrelated,
they are generationally close.
    Also, while you may be mostly concerned of the Puppy Linux version number,
the underlying graphics server is still X.org X Server.
Even for X Server, they do try to preserve backward compatibility between
versions as much as possible.
As a result, based on my own testing of VIA hardware with OpenChrome, I have
confirmed that OpenChrome Version 0.4.0 works fine with X Server Version 1.7 or
later and Linux kernel 2.6.32 or later.
Please note the "later" part.
Because X.org tries to preserve backward compatibility as much as possible. it
has been reported here and there that OpenChrome Version 0.4.0 appears to be
working pretty well with various X Servers and Linux kernels (I hope it will
work with BSD as well.).

https://lists.freedesktop.org/archives/openchrome-devel/2016-March/002177.html
https://lists.freedesktop.org/archives/openchrome-users/2016-April/007260.html

Arch Linux was the first Linux distribution to take in OpenChrome Version 0.4.0
after release, and apparently it is now in their "extra" repository along with
stuff from Intel and Nouveau (reverse engineered open source NVIDIA graphics
display driver).

https://www.archlinux.org/packages/extra/i686/xf86-video-openchrome/

If you sort it by "Last Updated," you can see that other than the "Big 3" of
x86 platform graphics, we are the other 2 actively maintained graphics device
driver (the other is r128) based on the last updated date.

https://www.archlinux.org/groups/i686/xorg-drivers/

What I am trying to say is that OpenChrome Version 0.4.0 has been tested fairly
extensively already by many VIA silicon hardware owners (it has been available
for only a week), and it is working fairly well for a release where I had to
take some design risks (i.e., removing known device table, moving towards full
automatic display detection, etc.).
This, along with the fact that I spent some of my own money to buy Wyse C00X
for testing purpose specifically because you really wanted this bug fixed, I do
not think I will be the only one who might think that my effort is not being
totally appreciated.
Christopher, please remember that since November 2015, I probably spent the
most time fixing your bug than fixing other bugs like standby mode resume bug
with VIA IGP laptops I wanted to fix for myself and another person.
There are other bugs other people want fixed.

> You don't need a network stack to follow my instructions as provided, except
> to download packages and code to a flash drive on another,
> Internet-connected system that is not the target machine. All you need as
> far as the Wyse Cx0 is concerned are -- my instructions, a bootable drive
> with Puppy, and either a folder on that drive or a second drive containing
> current openchrome code, the "devx" for Puppy, and the additional packages
> that satisfy build deps. The Wyse client itself need never connect to a
> network for these purposes, and indeed mine has not yet done that in the
> time I've owned it.
> 

Please remember that while Puppy Linux is a unique platform as far as Linux
goes, it is also different in terms of GUI operation and network stack support
compared to other Linux based OSes I have used in the past (i.e., Lubuntu,
Xubuntu, etc.).
As a developer, it is very draining to have to spend my own precious time
figuring out how to operate the OS itself just to do some basic things like
connecting to the Internet or copying files.
What might be intuitive to you might not be intuitive to me as a first time
Puppy Linux user.

> Nevertheless, as reported previously, I've ordered another WYSE Cx0 from
> eBay -- specifically, a C90LEW. I believe that the only changes in the
> design between C90LE and C90LEW relate to internal Disk-On-Module and RAM
> capacity when shipped... we will see what happens with that when it arrives.
> 

I am sorry to hear that you need to spend more of your own precious money on
validation when you have publicly mentioned that you could not really afford
to.

> If it is my environment, I suspect I know what the issue is and replacing
> the client will fix that. At some point I replaced the thermal material
> under the heatsink with much better stuff, which is unfortunately somewhat
> conductive -- it could be a short there, or it could be the one single
> surface-mount passive I knocked off in the process of undoing one of the
> spring-pins for the heatsink. I did not previously report this damage,
> because the client operates 100% fine in every other respect that I have
> tested it with. Usually, in my experience, motherboard damage is either
> inconsequential or fatal.
> 
> Nevertheless -- testing is the only way to know for sure; I will do the
> testing, since you've made it clear that you will not.
> 

The only logical conclusion I can come up with after all the tests I have done
and all the feedback I received from other people is that either 1) you are not
compiling OpenChrome correctly, 2) you did not install OpenChrome correctly, 3)
there is a bug in the particular Puppy Linux version you are using, or 4)
hardware failure with your equipment.
As far as my own testing is concerned, a DVI to VGA adapter is now working with
Wyse C00X and Puppy Linux 5.7.1 with the latest OpenChrome.
If you try Puppy Linux 5.7.1 with the latest OpenChrome, and it is working,
then you will need to suspect hardware failure or a bug of Puppy Linux, not
OpenChrome.
I am not responsible for a Puppy Linux bug (in general), and you need to get
their developers to deal with that.
You sound like you are blaming me or OpenChrome code, and I prefer if you do
not do this since I do perform quite a bit of testing using my own 10+ VIA
silicon hardware equipment at my place.
I fixed a regression that seems to have occurred 2 weeks prior to the Version
0.4.0 release (The one Xavier Bachelot appears to be making an issue out of it
right now. I am not trying to criticize him here.), and all other known bugs
are disclosed in the README file that came with the release (I will post this
on the mailing list soon.).
    Theoretically, I can do what I proposed in the past with Puppy Linux 6.0.x.
I can compile OpenChrome using an older version of Lubuntu 14.04 (Canonical did
a kernel upgrade to Linux 4.2 kernel from 3.13 or 3.14 it used in the past.
Puppy Linux 6.0.5 uses Linux 3.14 kernel, so I should probably stick with an
older kernel.), and then copy the compiled OpenChrome to Puppy Linux 6.0.x.
I will need to find some time to do this, but if OpenChrome works with this
configuration, then I just wasted my time trying to prove something I did not
really wanted to spend my time on.

> Again -- I do appreciate all of what you've done. "It's been a long road,
> getting from there to here..." ;) and I honestly cannot thank you enough for
> all of the help you've given me.
> 
> When I can next report back with a logfile, I will do so... until then I
> will probably be silent. It may be a week or two... but I'm not gone yet,
> I'm just resting ;)

Yes, from now on, please upload Xorg.0.log after you conduct your own test.
I no longer will take "it didn't work" alone as a valid answer considering that
I consider this bug technologically closed.
Again, many users are now reporting that DVI to VGA is working, and I, myself,
has seen that OpenChrome works with VX855 chipset.
I am repeating myself again, but in the long run, you need to get Puppy Linux
developers to replace old OpenChrome with the latest one.
OpenChrome Version 0.3.3 has so many problems that it needs to be retired for
good.
I will still devote some of my time on your bug from time to time (i.e., I will
not ignore your bug report or you.), but I will need to reduce my time
resources dedicated to your bug since I have many more pressing issues I need
to work on, and from a technological perspective, the bug was fix with the
release of OpenChrome Version 0.4.0.
External TMDS transmitter (DVI) support is planned for the next release of
OpenChrome.
It will likely be called Version 0.5.0 since I just adopted X.org version
numbering scheme.

-- 
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/20160407/aa3b23e9/attachment-0001.html>