Hi Dariusz,

This looks like a duplicate of Bug 92711 and Bug 94130 even though the chipset is different.
I am not sure where you exactly obtained the code, but I can tell from Xorg.0.log that the code you used is not the latest master branch code.
I wrote a tutorial on how to install the latest master branch code, so please follow the instructions.

https://lists.freedesktop.org/archives/openchrome-devel/2016-February/001753.html

Let me know what happens with the latest master branch code.

Hi Dariusz,

Okay, I just noticed that you have a Canonical e-mail address.
I am the project maintainer for OpenChrome at this point (I obtained commit privilege about 2 weeks ago.) since no one other than myself has done commits for the past 8 months or so.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/

I am getting OpenChrome Version 0.3.4 ready for release within a week, and I will like to know how I can get Canonical to adopt it.

https://lists.freedesktop.org/archives/openchrome-devel/2016-February/001745.html

This is what I will like to see happen.

- For those Ubuntu with OpenChrome Version 0.3.3, please replace it with OpenChrome Version 0.3.4.

This includes Ubuntu 14.04 LTS and later releases.
Version 0.3.3 has the very bug you are dealing with, and this bug has been fixed between the current master branch and when Version 0.3.3 was released.

- For those Ubuntu with OpenChrome Version 0.2.x, please hold off from updating it with OpenChrome Version 0.3.4 at this point

I am talking about Ubuntu 12.04 LTS specifically.
This is due to the fact that there is a bug in the code that affects computers with a DVI-I output (i.e., a DVI connector that has both DVI and VGA signals come out of it), and more specifically, if DVI to VGA adapter is used.
This feature was working in OpenChrome Version 0.2.904 that shipped with Ubuntu 12.04 LTS.
Unfortunately, OpenChrome Version 0.3.x appear to have broken it.

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

It is taking a long time in fixing this bug due to the fact that the person who reported it uses a thin client (i.e., no hard drive), and he needs to update his SD card to boot PuppyLinux (Ubuntu based).
I do not really have a functioning computer with VIA Technologies IGP that comes with DVI-I at this point, so I am not really able to fix it in a timely manner.
Version 0.3.4 will likely ship without fixing this bug.
I will try to fix this bug in the future release.

Hello Dariusz.
Unfortunately the backtrace is not so useful as it could be with debug symbols.

Please install following packages, reproduce crash and paste Xorg.0.log file.

  sudo apt-get install xserver-xorg-core-dbg xserver-xorg-video-openchrome-dbg


Also I would recommend to build latest openchrome version from git, with Debug symbols enabled. It could be easily done with following commands:

    git clone git://anongit.freedesktop.org/openchrome/xf86-video-openchrome
    cd xf86-video-openchrome
    ./autogen.sh --prefix=/usr --enable-debug --enable-xv-debug
    make
    sudo make install

More information how to build and install you could find at:
https://www.freedesktop.org/wiki/Openchrome/Installation/

or:

https://help.ubuntu.com/community/OpenChrome

Created attachment 121928 [details]
Updated Xorg log produced using the git head

Thank you Bartosz. Unfortunately the debugging symbols were already installed - despite this fact the stacktrace remains cryptic.

The latest HEAD from git (built according to https://lists.freedesktop.org/archives/openchrome-devel/2016-February/001753.html) produces a different Xorg (update attached). However, the card remains unrecognized, but this time no segfault occurs - hopefully this was fixed by https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=ecb1695ac2de1d840c036f64b5b71602e0f522a4

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.

(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.

(In reply to Kevin Brace from comment #6)
> If necessary, I can release OpenChrome Version 0.3.4 immediately,

I'd say: release as soon as possible.  You can always release 0.3.5 a week later, or two, or whenever.  There's not just Canonical to consider, there are likely also users of Arch and Debian and Gentoo and other distros who will grab the new version and test it.  The earlier, the better.

Created attachment 121948 [details]
attachment-27653-0.html

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 <https://bugs.freedesktop.org/show_bug.cgi?id=94210#c6>  on bug 94210 <https://bugs.freedesktop.org/show_bug.cgi?id=94210>  from  <mailto:kevinbrace@gmx.com> Kevin Brace 

(In reply to Dariusz Gadomski from comment #5 <https://bugs.freedesktop.org/show_bug.cgi?id=94210#c5> )
 
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.

(In reply to HuangRan from comment #8)

Hi Frank,

> 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

We could remove the table, or maybe for now, we could just disable it.
My view is that by in about 1 to 2 more releases after Version 0.3.4, the table will be removed or disabled.
I am just trying to avoid making substantial changes for soon to be released Version 0.3.4.
I am also considering getting rid of VESA BIOS Extension (VBE) support at the same time.
VBE support is not longer necessary since most devices can be detected automatically.
I still think that a small "quirk" table may be necessary (i.e., Linux kernel has it) in some cases, but only for very few devices that truly need it.
In a sense, this weird known device table is a very large quirk table, and I think it outlived its usefulness.

Hi Kevin,

   Sorry to reply previous mail directly instead Bugzilla which generates two copies of my reply.
   For that ViaCardID table, I think the only useful idea is for guys who wanted to invovle OpenChrome development to buy a board which is in that list:). I checked the RADEON KMS driver, actually when it determines whether the driver can support a board or not, it will see the deviceID and vendorID which will skip subDeviceID and subVendorID. So I suggest to disable this table too as you said.
   For quirk table, I also notice that in current KMS driver, sometimes we will use quirk table for some specific vendor's devices which we can adopt.
   For VBE, I see the log shows:
             "[  1197.429] (==) CHROME(0): Will not enable VBE modes."
   So it seems VBE is not used anymore although the code is there, right?

Thanks,
Frank

(In reply to HuangRan from comment #10)

Hi Frank,

> Hi Kevin,
> 
>    Sorry to reply previous mail directly instead Bugzilla which generates
> two copies of my reply.
>    For that ViaCardID table, I think the only useful idea is for guys who
> wanted to invovle OpenChrome development to buy a board which is in that
> list:). I checked the RADEON KMS driver, actually when it determines whether
> the driver can support a board or not, it will see the deviceID and vendorID
> which will skip subDeviceID and subVendorID. So I suggest to disable this
> table too as you said.
>    For quirk table, I also notice that in current KMS driver, sometimes we
> will use quirk table for some specific vendor's devices which we can adopt.
>    For VBE, I see the log shows:
>              "[  1197.429] (==) CHROME(0): Will not enable VBE modes."
>    So it seems VBE is not used anymore although the code is there, right?
> 
> Thanks,
> Frank

The thing is, VBE code is still inside OpenChrome, and can be activated as an option.
Even as a backup, I still do not like its mere existence.
If people want to rely on VBE, they should use VESA device driver instead as a fallback.
There are other things that should be removed from the code like software cursor option, in my opinion, assuming that the code will always display mouse cursor correctly (This is not the case with Lubuntu 10.04. Even the software cursor is broken in Lubuntu 10.04).
    As a general rule, I do not really like legacy stuff that has outlived its usefulness.
VBE option and known device table are such examples.

Hi Kevin,

> 
> The thing is, VBE code is still inside OpenChrome, and can be activated as
> an option.
Okay. So do you mean "vga=XXX" option in grub?

> Even as a backup, I still do not like its mere existence.
> If people want to rely on VBE, they should use VESA device driver instead as
> a fallback.
Agree on that. xf86-video-vesa can be used with VBE. And current new driver(i.e. Intel/ATI) does not apply VBE anymore. They have already has its CRTC/Encoder/Connector routines to initialize the port and video card.

> There are other things that should be removed from the code like software
> cursor option, in my opinion, assuming that the code will always display
> mouse cursor correctly (This is not the case with Lubuntu 10.04. Even the
> software cursor is broken in Lubuntu 10.04).
For SW cursor option, I suggest you keep it now. Because based on my experience before, for some cases(i.e. rotation), the HW cursor has the possibility to be broken.

>     As a general rule, I do not really like legacy stuff that has outlived
> its usefulness.
> VBE option and known device table are such examples.
:). I does not like legacy stuff too.

Thanks,
Frank

Okay，I found if we remove ViaCardID table directly, there are some possible issue. i.e., for notebook(i.e., your environment), there is an option named VIA_DEVICE_LCD which is used by LVDS initialization function(via_lvds_init). If "ForcePanel" is disabled and pVia->Id->Outputs does not have VIA_DEVICE_LCD flag, the output is not created anymore which could lead X crash.

Thanks,
Frank

(In reply to HuangRan from comment #12)

Hi Frank,

> Hi Kevin,
> 
> Okay. So do you mean "vga=XXX" option in grub?
> 

No, the option to activate VBE in xorg.conf.
These 2 links talk about some of the options xorg.conf can have.

https://www.freedesktop.org/wiki/Openchrome/Configuration/
https://www.freedesktop.org/wiki/Openchrome/SuppaortedHardware/

VBE is mentioned, although it is not well explained.


> Agree on that. xf86-video-vesa can be used with VBE. And current new
> driver(i.e. Intel/ATI) does not apply VBE anymore. They have already has its
> CRTC/Encoder/Connector routines to initialize the port and video card.
> 

Yes, display initialization support is near complete, at least on paper.
This is why I think the time has come to remove VBE support.


> For SW cursor option, I suggest you keep it now. Because based on my
> experience before, for some cases(i.e. rotation), the HW cursor has the
> possibility to be broken.
> 
> :). I does not like legacy stuff too.
> 
> Thanks,
> Frank

Yeah, we can leave the software cursor option for now, but in the long run, the support for it should be dropped.
I do agree that it should not be remove in the near future.

Hey Kevin

(In reply to Kevin Brace from comment #6)
> 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.

Ok, so if the unknown Card-id is not the problem do you see anything suspicious there that could be the reason of a blank display currently? After switching the display driver to VESA X starts up the given app correctly, while using OpenChrome it stops at a blank display.

The only suspicious lines I could spot there are:
(EE) CHROME(0): [drm] Failed to open DRM device for pci:0000:00:01.0: No such file or directory
(...)
(EE) AIGLX: reverting to software rendering

but I guess in that case it should just work without hardware rendering. Do you think anything else that could cause that behaviour?


> 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.
> (...)
> 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?

It's totally doable for 16.04.1 once the release is ready - I will provide any help necessary in that area.

Regarding 14.04: I will be more than happy to help you with backporting the fix and releasing it on top of 0.3.3 - as this is what the SRU allows.

Was this the fix you had in mind for this issue?
https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=ecb1695ac2de1d840c036f64b5b71602e0f522a4

Once we agree on which changes are needed to backport I can start with the paperwork.

However, I doubt that the Ubuntu Security Team would agree to introduce a whole new release of the driver to a stable release as a security update.
There are some rigid requirements for this: https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures

Nonetheless I can provide any help necessary to fix the already-released 0.3.3.

Hi Kevin,

   Sorry for late reply.
   Yup, "VBEModes" option can be used in xorg.conf to enable VBE mode.
   And for "vga=xxx" option, please see:
      https://en.wikipedia.org/wiki/VESA_BIOS_Extensions
   It can also be used for VBE setting I think.
   As far as I digged into the OpenChrome code, I found right now DP/HDMI port is not supported, especially for VX900. So do think VBE can be used before they are supported?

Thanks,
Frank

(In reply to Kevin Brace from comment #14)
> (In reply to HuangRan from comment #12)
> 
> Hi Frank,
> 
> > Hi Kevin,
> > 
> > Okay. So do you mean "vga=XXX" option in grub?
> > 
> 
> No, the option to activate VBE in xorg.conf.
> These 2 links talk about some of the options xorg.conf can have.
> 
> https://www.freedesktop.org/wiki/Openchrome/Configuration/
> https://www.freedesktop.org/wiki/Openchrome/SuppaortedHardware/
> 
> VBE is mentioned, although it is not well explained.
> 
> 
> > Agree on that. xf86-video-vesa can be used with VBE. And current new
> > driver(i.e. Intel/ATI) does not apply VBE anymore. They have already has its
> > CRTC/Encoder/Connector routines to initialize the port and video card.
> > 
> 
> Yes, display initialization support is near complete, at least on paper.
> This is why I think the time has come to remove VBE support.
> 
> 
> > For SW cursor option, I suggest you keep it now. Because based on my
> > experience before, for some cases(i.e. rotation), the HW cursor has the
> > possibility to be broken.
> > 
> > :). I does not like legacy stuff too.
> > 
> > Thanks,
> > Frank
> 
> Yeah, we can leave the software cursor option for now, but in the long run,
> the support for it should be dropped.
> I do agree that it should not be remove in the near future.

(In reply to Dariusz Gadomski from comment #15)

Hi Dariusz,


> Hey Kevin
> 
> Ok, so if the unknown Card-id is not the problem do you see anything
> suspicious there that could be the reason of a blank display currently?
> After switching the display driver to VESA X starts up the given app
> correctly, while using OpenChrome it stops at a blank display.
> 
> The only suspicious lines I could spot there are:
> (EE) CHROME(0): [drm] Failed to open DRM device for pci:0000:00:01.0: No
> such file or directory
> (...)
> (EE) AIGLX: reverting to software rendering
> 
> but I guess in that case it should just work without hardware rendering. Do
> you think anything else that could cause that behaviour?
> 
> 

I am a little getting lost.
Are you saying that the current master branch OpenChrome code produces a blank screen after OS boots?
One known configuration that causes this is if you use DVI to VGA adapter.
Another configuration is if you use VX900 chipset (or possibly CX700, VX700, VX800, or VX855 chipset) where VGA is not available, device is detected via weird known device table, and LCD enable option is not listed in the weird known device table.
If you can clarify your particular system configuration, that will be appreciated.


> It's totally doable for 16.04.1 once the release is ready - I will provide
> any help necessary in that area.
> 

Okay, that is fair.
People who install Ubuntu 16.04 LTS will eventually update system via patches, so they will eventually get the fix via Update Manager.


> Regarding 14.04: I will be more than happy to help you with backporting the
> fix and releasing it on top of 0.3.3 - as this is what the SRU allows.
> 
> Was this the fix you had in mind for this issue?
> https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/
> ?id=ecb1695ac2de1d840c036f64b5b71602e0f522a4
> 

You are probably right that the particular commit fixes the bug.
That being said, this happened way before I assumed the project maintainer role, so there is no incentive for me to figure this out.


> Once we agree on which changes are needed to backport I can start with the
> paperwork.
> 
> However, I doubt that the Ubuntu Security Team would agree to introduce a
> whole new release of the driver to a stable release as a security update.
> There are some rigid requirements for this:
> https://wiki.ubuntu.com/SecurityTeam/UpdateProcedures
> 
> Nonetheless I can provide any help necessary to fix the already-released
> 0.3.3.

I do understand that Canonical people do not want to tinker with the code, and "think" that the current code is stable.
It is not.
Between Version 0.2.904 (used by Ubuntu 10.04 LTS and 12.04 LTS) and Version 0.3.3, the previous developer broke VGA detection code if DVI to VGA adapter is used.
This is a fatal regression.
One of the reason why I am holding up Version 0.3.4 release is due to this.
The major difference between Version 0.2.x and Version 0.3.x is the OpenChrome DDX support for KMS.
However, the DRM module that supports KMS has not been mainlined, and the instructions on building was not sufficient for me to build it for now.

https://www.freedesktop.org/wiki/Openchrome/TtmGemKms/

Other than that, there is little difference in terms of feature support.
As far as I know, the compilation infrastructure used to compile OpenChrome has not changed, so OpenChrome Version 0.3.4 should completely replace OpenChrome Version 0.2.904 assuming that I can figure out the DVI to VGA adapter VGA detection issue.
At the very least, Version 0.3.3 should be replaced with Version 0.3.4 as soon as possible since Version 0.3.4 is merely a bug fix released compared to Version 0.3.3.

I am totally supportive for Kevin's suggestion to make 0.3.4 to be merged into latest Linux distribution OS. No need to wait anything on that!
For example, for DVI VT1632 support, v0.3.3 does not have it supported because this file is added in 2015/1 which is not merged in v0.3.3. Furthermore, Recently, Kevin helped OpenChrome users fixed a lot of mode setting bugs which improved driver's stability.
By the way, to make OpenChrome in a more active working mode, we have to make an unreleased 0.3.4 driver released as soon as possible since last release 3 years ago!
Then after I worked on KMS driver for OpenChrome and new chip VX11, I definitely want this project more active!

Thanks,
Frank

This bug was already fixed with commit:
https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=ecb1695ac2de1d840c036f64b5b71602e0f522a4

(In reply to Kevin Brace from comment #17)
Hi Kevin

> I am a little getting lost.
> Are you saying that the current master branch OpenChrome code produces a
> blank screen after OS boots?

That's true.

> One known configuration that causes this is if you use DVI to VGA adapter.
> Another configuration is if you use VX900 chipset (or possibly CX700, VX700,
> VX800, or VX855 chipset) where VGA is not available, device is detected via
> weird known device table, and LCD enable option is not listed in the weird
> known device table.
> If you can clarify your particular system configuration, that will be
> appreciated.

The device has a DVI *and* VGA output and while using DVI output (without adapter of any kind) we're getting a blank output. VGA output to VGA display works fine - this is what we use currently as a work-around.

This is another issue however and is probably related to the topic you mentioned above and is not related to this bug.

> I do understand that Canonical people do not want to tinker with the code,
> and "think" that the current code is stable.
> It is not.
> Between Version 0.2.904 (used by Ubuntu 10.04 LTS and 12.04 LTS) and Version
> 0.3.3, the previous developer broke VGA detection code if DVI to VGA adapter
> is used.
> This is a fatal regression.
> One of the reason why I am holding up Version 0.3.4 release is due to this.

I fully agree with you and I also want to see this fixed and present in Ubuntu. Unfortunately the rules (btw. those are Ubuntu rules rather than Canonical) are very strict and I don't think they can be bypassed in any way other that those described at the wiki pages (SRU and MRE).

However, I would still like to provide any help necessary in making sure the new releases will be included in upcoming Ubuntu releases. Would you mind if we continue the discussion on the openchrome-devel mailing list?

Thank you,
Dariusz