Hi Kevin,

Recent two days, I am looking into the UMS xf86-video-openchrome code and also be shocked by ViaCardID[] struct in Via_id.c file. Why does the UMS driver use this table to identify the board? I am also buying some old boards including VX700/VX855/VX900 and I found some boards(i.e., Wyse Thin Clients) are not in this list. So I can guess same error will be reported.

So It seems this ViaCardID table will only bring faults instead of any good things. Why not remove it?

Thanks,

Frank

发件人: Openchrome-devel [mailto:openchrome-devel-bounces@lists.freedesktop.org] 代表 bugzilla-daemon@freedesktop.org
发送时间: 2016 年2月24日 12:15
收件人: openchrome-devel@lists.freedesktop.org
主题: [Openchrome-devel] [Bug 94210] Unknown Card-Ids (7122|1458|D000), Chipset: VX900

Comment # 6 on bug 94210 from Kevin Brace

    (In reply to Dariusz Gadomski from comment #5)

    Hi Dariusz,

    > 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

    > (https://wiki.ubuntu.com/StableReleaseUpdates) 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.

    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.

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

    If necessary, I can release OpenChrome Version 0.3.4 immediately, and fix DVI

    related bugs in Version 0.3.5.

You are receiving this mail because:

- You are the assignee for the bug.