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: