https://bugs.freedesktop.org/show_bug.cgi?id=94130
--- Comment #10 from Kevin Brace <kevinbr...@gmx.com> ---
(In reply to Jeffrey Walton from comment #9)
Hi Jeffrey,
> It looks like Debian took the update at
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=814682.
>
> The patch appears to be available in Ubuntu in the -proposed repository. I
> tested the proposed patch from Debian upstream under Ubuntu, and the machine
> tested OK.
>
> The machine also tested OK with the manual patch as outlined by Kevin Brace
> at
> http://lists.freedesktop.org/archives/openchrome-users/2016-February/007234.
> html.
>
> **********
>
> For Ubuntu users, they can follow
> http://wiki.ubuntu.com/Testing/EnableProposed. Here's the 3 second tour
> using Wily/15.10:
>
> $ cat /etc/apt/sources.list | tail -2
> deb http://archive.ubuntu.com/ubuntu/ wily-proposed restricted main
> multiverse universe
>
> $ cat /etc/apt/preferences.d/proposed-updates
> Package: *
> Pin: release a=wily-proposed
> Pin-Priority: 400
>
> Then, 'apt-get update'. Finally:
>
> $ sudo apt-get install xserver-xorg-video-openchrome/wily-proposed
>
> After "xserver-xorg-video-openchrome" is installed from proposed, the new
> driver will be used.
>
> **********
>
> The above arte instructions for testing by Ubuntu users.
>
> I think the actionable item here for the Free Desktop folks is to close this
> bug for the PM400 chipset as it appears to be fixed and confirmed.
I have been spending quite a bit of time on OpenChrome development for the past
6 weeks (have done about 30 commits so far), and it is my view that it might
take something like several months before there is a releasable version.
The problem here is that the code to handle DVI is not working well with many
not so obscure hardware (i.e., HP T5550 thin client with VX900 chipset), and
after trying to fix the existing code, I decided to remove several features
that was contributing to the brokenness of the code.
I will be rewriting the code in a major way (already well underway), and the
rewritten code will use hardware "hints" (i.e., strapping resistors) to figure
out what hardware configuration OpenChrome is dealing with.
For some reason, previous developers were not using this, and instead was
relying on users reporting what display type is connected to the hardware (This
feature has since been removed by me. Good riddance.).
This should be particularly effective for VX900 chipset since it has a way to
tell OpenChrome what display resource is connected to the chipset, at least for
DVI and LVDS flat panel.
I honestly did not want to delay the release of OpenChrome this long, but since
I have already made substantial updates to the code, I will need to complete
the changes, and stabilize the code.
When it is ready, I will likely call this OpenChrome Version 0.4.0 since
several undesirable (hard to maintain) legacy features have already been
retired (i.e., VESA BIOS Extension mode setting support, known device table,
"legacy" mode setting, etc.).
--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel
