[Openchrome-users] OpenChrome Version 0.4.0

[hzh]

[warning, somewhat lenghthy post]

Hello Kevin, Frank and everybody else team,

congratulations on 0.4.0!

I also read your "blog-style" post, Kevin. It's good to see that  
someone gives the old HW does some love. :) Moreover I agree: A lot of  
use cases don't need that much of raw processing power. Though we do  
have e.g. Kabinis from AMD's side, the offer moderate (surprisingly  
good) computing power and also use few electric energy.

But for the ones still with VIA HW around this release is magnificent news.

By the way, I think that a lot of thin clients uses VIA HW, so in that  
area the market share might actually be larger. And back in the days,  
VIA was quite in a good position with their low power small form  
factor Mini-ITX boards. Sadly it never really took off, for once I  
guess due to the lack of development support / decent drivers, for the  
other part maybe due to strange combinations (HTPC suitable boards but  
loud and noisy fan). But that is just my speculation.


I'm also very happy for the initial dual head support!
I remember an important presentation of mine, some time ago (defense  
of an academic degree). Just few days before the actual defense I had  
a test talk in front of my colleagues and I was still on my CLE266/C-3  
based notebook. And just before the talk I found that openchrome (or  
was it still unichrome at that time? even xf86-video-via?) did not  
support dual screen (beamer). Luckily I had fetched the  
xf86-video-vesa sources and found myself compiling (Gentoo)  
xf86-video-vesa just minutes before the talk and change my xorg.conf  
and restart seconds before people entered the room. So at least I had  
dual screen support via vesa driver - but no video acceleration. So a  
video I showed was stuttering.
Haha, wild old times. ;)

So even though I don't use that laptop these days (IDE connector  
somehow broke / got loose) I am still happy for the multi output  
support.


> as automatic as possible when it comes to display detection.

Good thing that. I remember I did have some severe troubles with a few  
attached TFT monitors in the past (all via D-Sub VGA). All of them  
would work e.g. with my radeons, or an AMD Geode LX setup. Or with a  
VESA driver. But on some VIA based board, when running openchrome, the  
BIOS + text (80x25) console would boot up nicely - but as soon as  
openchrome / X kicked in, the signal was lost or faulty. So no X  
unless I was using VESA or something like it.

You describe "kown device tables"... do these relate to the pure video  
outputs for chipsets or IGP / dGP PCB boards (some board vendors have  
DVI capable chips but solder only a D-Sub VGA) or ... does it even  
relate to monitors?
I thought mode setting / possible mode detection would be done somehow  
via EDID information downloaded from the monitor (unless it is an  
ancient 8" b&w CRT one :-) ). So I guessed something might be wrong  
with the EDID itself (but radeon or vesa driver parsed it correctly?)  
or something in the processing of the EDID info? Or does the know  
device table deal more with the very GPUs with their PCI vendor ids  
and such?

Sadly I do not have that specific device combination anymore (where I  
could reproduce that); it stayed at work when I finished my practical  
PhD work at the university. If I hit one of these issues again I'll  
try to find out as much as I can about it and file a bug report. I  
still got a few old panels around and some VIA boards so if I find the  
time I shall try.


> works fine with x.org X server 1.7 or later and Linux 2.6.32 or later

Fine for me, though I consider 2.6.32 rather old, kind of  
Debian-stable-old. ;)


> this developmental DRM module requires Linux kernel 3.18 or later  
> due to it using the latest TTM API.

No problem for me. I usually run 4.4.x on my machines now (Gentoo  
rolling release) - unless I hit strange ACPI problems that prevent  
booting *rolls eyes*. (but acpi=off disables power management which  
would be sad)



> Regarding CLE266, the current code has a bug with ACPI S3 State  
> resume, and I eventually plan to work on a fix for this bug, but it  
> is somewhat of a low to medium priority item at this point (fixing  
> DVI is the most urgent).

Well, S3 would be interesting for me on a CN700 - but for S3 a lot of  
things come into play. And ACPI is a minefield.
But yes, to get any image via DVI is a more pressing issue right now.


> I do have 2 mainboards with CLE266 (EPIA based), and I test it  
> regularly with one of them (i.e., EPIA-M).

I have that old Laptop (ECS G-320 and spare parts) with the CLE266,  
the mentioned CLE266 board that is now gone, and some C7 mini-ITX  
boards (one might actually be an EPIA, got it cheap and used - the  
other one is a Jetway but similar to the EPIAs and actually in use),  
and some more or less horrible thin clients (firmware doesn't allow  
USB boots, limited set of interfaces, hard to get your own Linux on  
them - but I'm working on it as time permits; and maybe I can ask the  
guy at parkytowers for some hints...).


> so that OpenChrome does not get dropped from Linux based OSes in the  
> near future.

That would not be good. It is still in Gentoo, though 0.3.3 as of now  
(April, 06th, 2016). I mean, openchrome still offers much more than a  
pure VESA driver for most users with that HW.
But I guess with that activity it will not drop off the world's surface. :)


Cheers and thanks for your work
Haldor