<html>
    <head>
      <base href="https://bugs.freedesktop.org/" />
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Unknown Card-Ids (7122|1458|D000), Chipset: VX900"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=94210#c6">Comment # 6</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - Unknown Card-Ids (7122|1458|D000), Chipset: VX900"
   href="https://bugs.freedesktop.org/show_bug.cgi?id=94210">bug 94210</a>
              from <span class="vcard"><a class="email" href="mailto:kevinbrace@gmx.com" title="Kevin Brace <kevinbrace@gmx.com>"> <span class="fn">Kevin Brace</span></a>
</span></b>
        <pre>(In reply to Dariusz Gadomski from <a href="show_bug.cgi?id=94210#c5">comment #5</a>)

Hi Dariusz,

<span class="quote">> Kevin, I will appreciate taking a look at the updated Xorg.log - the
> segfault is gone, but the driver still does not recognize the card.

> Regarding your expectations towards 0.3.4 version adoption in Ubuntu:
> unfortunately the Stable Release Updates policy
> (<a href="https://wiki.ubuntu.com/StableReleaseUpdates">https://wiki.ubuntu.com/StableReleaseUpdates</a>) prevents upgrading packages
> during the lifetime of the stable releases. The only available option seems
> to be backporting individual changes (in response to reported bugs) to the
> version already available in a particular release.

> Sadly, we also missed the opportunity to release it with 16.04 - as it has
> entered the feature freeze state.

> I will check if there are any other options.</span >

Thank you very much for getting back with me.
Please ignore the unknown device message you see in Xorg.0.log.
This occurs due to the use of a weird known device table inside OpenChrome.
I am not a fan of the use of something like this, 
The code is gradually moving towards all automatic detection of display
devices, but this will take some time to complete.
I am considering getting rid of this weird known device table in OpenChrome
Version 0.3.5, but I will likely keep it in there for Version 0.3.4.
This is what the weird known device table looks like

_____________________________________________________________________________
. . .
    /*** VX900 ***/
    {"Simmtronics SIMM-PC VX900i",            VIA_VX900,   0x1019, 0x3126,
VIA_DEVICE_CRT},
    {"ECS VX900-I",                           VIA_VX900,   0x1019, 0x7C8E,
VIA_DEVICE_CRT},
    {"Foxconn L740",                          VIA_VX900,   0x105B, 0x0CFD,
VIA_DEVICE_LCD | VIA_DEVICE_CRT},
    {"HP T5550 Thin Client",                  VIA_VX900,   0x1106, 0x7122,
VIA_DEVICE_CRT},
    {"Biostar Viotech 3200+",                 VIA_VX900,   0x1565, 0x120A,
VIA_DEVICE_CRT},
    {"ASRock PV530",                          VIA_VX900,   0x1849, 0x7122,
VIA_DEVICE_CRT},
    {"Fujitsu Futro A300",                    VIA_VX900,   0xA0A0, 0x080F,
VIA_DEVICE_CRT},

    /* keep this */
    {NULL,                                    VIA_UNKNOWN, 0x0000, 0x0000,
VIA_DEVICE_NONE}
_____________________________________________________________________________


Looking at the link you provided, I feel like updating OpenChrome Version 0.3.3
is quite warranted based on the following clauses I saw in the link you
provided.

___________________________________________________________________________
2.1. High-impact bugs

Stable release updates will, in general, only be issued in order to fix
high-impact bugs. Examples of such bugs include:

. . .

- Bugs which represent severe regressions from the previous release of Ubuntu.
This includes packages which are totally unusable, like being uninstallable or
crashing on startup.

. . .

2.2. Other safe cases

In the following cases a stable release update is also applicable as they have
a low potential for regressing existing installations but a high potential for
improving the user experience, particularly for Long Term Support releases:

- Bugs which do not fit under above categories, but (1) have an obviously safe
patch and (2) affect an application rather than critical infrastructure
packages (like X.org or the kernel).
- For Long Term Support releases we regularly want to enable new hardware. Such
changes are appropriate provided that we can ensure not to affect upgrades on
existing hardware. For example, modaliases of newly introduced drivers must not
overlap with previously shipped drivers. This also includes updating hardware
description data such as udev's keymaps, media-player-info, mobile broadband
vendors, or PCI vendor/product list updates.

___________________________________________________________________________


Anyway, since the bug is a fatal one, and a severe regression from Version
0.2.904, is there a way the newer version can be treated as a security fix
update so that Canonical can replace OpenChrome Version 0.3.3?
Also, can OpenChrome Version 0.3.4 go into Ubuntu 16.04.1 LTS if not Ubuntu
16.04 LTS?
At this point, I will likely not release OpenChrome Version 0.3.4 since I have
not been able to fix the DVI related problems completely at this point,
although there was some progress on this front today.

<a class="bz_bug_link 
          bz_status_REOPENED "
   title="REOPENED - No signal to monitor with X and openchrome using VX855 chipset graphics"
   href="show_bug.cgi?id=91966#c211">https://bugs.freedesktop.org/show_bug.cgi?id=91966#c211</a>

If necessary, I can release OpenChrome Version 0.3.4 immediately, and fix DVI
related bugs in Version 0.3.5.</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>