Bug 106298

Created attachment 139203 [details]
Xorg.o.log

Hi Scott,

I do not think this is an OpenChrome DDX upstream bug.
This is essentially an Arch Linux packaging / configuration bug.
I can say this because of this portion that caught my eyes from Xorg.0.log.

___________________________________________
. . .
[  4717.773] (II) LoadModule: "openchrome"
[  4717.784] (II) Loading /usr/lib/xorg/modules/drivers/openchrome_drv.so
[  4717.785] (EE) Failed to load /usr/lib/xorg/modules/drivers/openchrome_drv.so: /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol: vgaHWFreeHWRec
[  4717.786] (II) UnloadModule: "openchrome"
[  4717.786] (II) Unloading openchrome
[  4717.786] (EE) Failed to load module "openchrome" (loader failed, 7)
. . .
___________________________________________


This situation is eerily similar to the situation mentioned in this thread.

https://lists.freedesktop.org/archives/openchrome-users/2017-January/007298.html


This seems to be the solution.

https://lists.freedesktop.org/archives/openchrome-users/2017-January/007306.html 


I hope that helps.

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com

(In reply to Scott from comment #0)
> Kevin,
> 
> First off, Thanks for your work on this.
> 
> On an Everex Via C7-D stepnote w/ P4M900 graphics, the openchrome drivers
> fails to load.
> 
> Pertinent lspci
> "01:00.0 VGA compatible controller: VIA Technologies, Inc.
> CN896/VN896/P4M900 [Chrome 9 HC] (rev 01) (prog-if 00 [VGA controller])
>         Subsystem: FIRST INTERNATIONAL Computer Inc CN896/VN896/P4M900
> [Chrome 9 HC]
>         Flags: bus master, 66MHz, medium devsel, latency 16, IRQ 9
>         Memory at a0000000 (32-bit, prefetchable) [size=512M]
>         Memory at c8000000 (32-bit, non-prefetchable) [size=16M]
>         [virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
>         Capabilities: [60] Power Management version 2
>         Capabilities: [70] AGP version 2.0
> "
>   
> The following attachments concern a driver built with
> https://aur.archlinux.org/packages/xf86-video-openchrome-git/
> that was updated to:
> "# Maintainer:  Peter Mattern <pmattern at arcor dot de>
> # Contributor: Koscheev "Ashen" Mikhail <fresh19991 at yandex dot ru>
> # Contributor: Pascal "hardfalcon" Ernster <aur at hardfalcon dot net>
> # Contributor: Marcel Dykstra <marcel dot dykstra at gmail dot com>
> 
> _pkgname=xf86-video-openchrome
> pkgname=$_pkgname-git
> pkgver=xf86.video.0.6.0.374.g3c882cf
> "
> 
> In Xorg.0.log the openchome module is unloaded after
> " [  4717.773] (II) LoadModule: "openchrome"
> [  4717.784] (II) Loading /usr/lib/xorg/modules/drivers/openchrome_drv.so
> [  4717.785] (EE) Failed to load
> /usr/lib/xorg/modules/drivers/openchrome_drv.so:
> /usr/lib/xorg/modules/drivers/openchrome_drv.so: undefined symbol:
> vgaHWFreeHWRec
> [  4717.786] (II) UnloadModule: "openchrome"
> [  4717.786] (II) Unloading openchrome
> "
> 
> I also tried Debian 9.4 following the recent blog advice.

Created attachment 139231 [details]
Latest Xorg.0.log

Latest Xorg.0.log w/ kernel blacklist vesafb,viafb

Hi Scott,

I will need to see kern.log also located under /var/log as well.
That being said, blacklisting does not appear to be working since OpenChrome DDX is not able to allocate the frame buffer.
Something is allocating the frame buffer before OpenChrome DDX can.

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com


(In reply to Scott from comment #3)
> Created attachment 139231 [details]
> Latest Xorg.0.log
> 
> Latest Xorg.0.log w/ kernel blacklist vesafb,viafb

Created attachment 139236 [details]
Latest xorg log

Kevin,

Progress

I tried a different invocation in the Grub kernel entry
video=vesa:off vga=normal

and after a screen with offset rows of black/white columns had a nice looking twm w/ xterms.

One quirk is that exiting did not return me to the console - just "snow".  The poweroff button still rebooted.  I've seen reports of this in my searches - if there is a known fix I'd appreciate it.

I choose Arch due to it's ease of building a driver from git.  I tried the non-git xf86-video-openchrome (not the latest) and it did not work. Should I stick with Arch32/openchrome-git, instead of Debian9, on this machine?

Hi Scott,

Is OpenChrome DDX working now?
Reading through Xorg.0.log, it appears OpenChrome DDX recognized the 1440 x 900 FP.
I assume you are using a window manager called twm.

https://en.m.wikipedia.org/wiki/Twm

Also, can you run the window manager without the "video=vesa:off vga=normal" GRUB entry?
    Thanks to you, I did find one very minor mistake in the FP detection code.
This minor mistake confused me since if the register value displayed were true, flat panel would not have been detected.
FP is fine; just the displayed value is from a different unrelated register.
    You will need to provide more on the issue you are having with the console.
Can you switch to the console (I assume you mean the virtual console you can switch to in Xubuntu with Ctrl + Alt + Fx) when you are in GUI mode with twm?
    Regarding Arch Linux, do you know the OpenChrome DDX version Arch has?
I know they have Version 0.6.0, but perhaps you might be referring to an even older version.
    Does the latest OpenChrome DDX upstream code work now with Debian 9?
As for Debian support status, I have gotten OpenChrome DDX upstream code to run on Debian 8 and CLE266 chipset (VIA EPIA-M mainboard).
I did have to incorporate the FBDEV blacklisting for viafb, vt8623fb and vesafb.

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com


(In reply to Scott from comment #5)
> Created attachment 139236 [details]
> Latest xorg log
> 
> Kevin,
> 
> Progress
> 
> I tried a different invocation in the Grub kernel entry
> video=vesa:off vga=normal
> 
> and after a screen with offset rows of black/white columns had a nice
> looking twm w/ xterms.
> 
> One quirk is that exiting did not return me to the console - just "snow". 
> The poweroff button still rebooted.  I've seen reports of this in my
> searches - if there is a known fix I'd appreciate it.
> 
> I choose Arch due to it's ease of building a driver from git.  I tried the
> non-git xf86-video-openchrome (not the latest) and it did not work. Should I
> stick with Arch32/openchrome-git, instead of Debian9, on this machine?

Openchrome DDX is working but is relatively unstable.

It will not run without the /etc/default/grub entry.

I initally used xorg-xinit, twm and xterm for testing.  Once I had a working screen, I went ahead and install lxqt, kwin and sddm.  sddm (qt5 display manager) would not start at all and there were errors about arch linux systemd and the keyboard.  Systemctl disable sddm.service and booting into the console (no Xorg) and startx loaded lxqt.  On opening lxterminal-qt, it the screen crashed and locked keyboard/touchpad.  The powerbutton still allowed for a reboot.

I rebooted and install xorg-xdm and was able to start lxqt which is relatively unstable.

On either logout or opening another virtual terminal from both twm and lxqt, I get a black screen with "snow" but the powerbutton still works for shutdown.

Hi Scott,

I am not sure what to say, but most code testing for OpenChrome DDX / DRM happens on Xubuntu / Lubuntu.
They use Xfce and LXDE window manager, respectively.
I choose these platforms because they are fairly straightforward in setting up the computer for development / testing.
If you wanted to see if your particular Everex laptop is capable of running OpenChrome DDX, you may want to install Xubuntu / Lubuntu 18.04 to see if the graphics works.
Generally speaking, VN896 chipset (mobile version of P4M900 chipset) gets the most attention because I use HP 2133 Mini-Note for OpenChrome development, and if there is a regression, I will notice it quickly.
As for other window managers, I do not actively test them at this point.
Outside of Xubuntu / Lubuntu, I have tested OpenChrome DDX / DRM on Debian 8 (DDX only mode setting and KMS both work) and OpenChrome DDX Version 0.6 on FreeBSD (Xfce as my window manager).
The FreeBSD version has issues with restoring analog (VGA) display right after standby resume, although there is a workaround in restoring the display (enter VT then go back to GUI).
I do not mean to blame you for anything, but I feel like some of the instabilities you are encountering might not be the fault of OpenChrome directly.

Kevin Brace
Brace Computer Laboratory blog
https://bracecomputerlab.com


(In reply to Scott from comment #7)
> Openchrome DDX is working but is relatively unstable.
> 
> It will not run without the /etc/default/grub entry.
> 
> I initally used xorg-xinit, twm and xterm for testing.  Once I had a working
> screen, I went ahead and install lxqt, kwin and sddm.  sddm (qt5 display
> manager) would not start at all and there were errors about arch linux
> systemd and the keyboard.  Systemctl disable sddm.service and booting into
> the console (no Xorg) and startx loaded lxqt.  On opening lxterminal-qt, it
> the screen crashed and locked keyboard/touchpad.  The powerbutton still
> allowed for a reboot.
> 
> I rebooted and install xorg-xdm and was able to start lxqt which is
> relatively unstable.
> 
> On either logout or opening another virtual terminal from both twm and lxqt,
> I get a black screen with "snow" but the powerbutton still works for
> shutdown.

The ease of switching openchrome-git <=> openchrome in Arch32, is offset by the relatively small community/resources. It also introduces an extra level of complexity with systemd - nVidia/amdgpu users need to generate an initramfs that has the video module. 

The notebook dual-boots Arch32/NetBSD 7.1.2.  If you're not aware, NetBSD provides a monolithic xorg that still uses openchrome 0.3.3 and a modular xorg.  Modular xf86-video-openchrome is based on the latest release and does not bulk build (I have not tried myself).

NetBSD 7.1.2 is running fairly well and I suspect that Debian 8/Devuan testing will too.

What I'm mulling over is how much effort to put into future use.  The wikipedia entry for Via indicates that they are actively developing cpu's capable of competing with AMD for the Chinese market.  Interestingly, the Deepin package list does not even provide an openchrome driver

"•  xserver-common 2:1.19.3-2deepin 
  •  xserver-xorg 1:7.7+19 
  •  xserver-xorg-core 2:1.19.3-2deepin 
  •  xserver-xorg-input-all 1:7.7+19 
  •  xserver-xorg-input-libinput 0.23.0-2 
  •  xserver-xorg-input-synaptics 1.9.0-3deepin 
  •  xserver-xorg-input-wacom 0.34.0-1 
  •  xserver-xorg-video-all 1:7.7+19 
  •  xserver-xorg-video-amdgpu 1.3.0-1 
  •  xserver-xorg-video-ati 1:7.9.0-1 
  •  xserver-xorg-video-fbdev 1:0.4.4-1+b5 
  •  xserver-xorg-video-intel 2:2.99.917+git20161206-1+deepin 
  •  xserver-xorg-video-nouveau 1:1.0.15-2 
  •  xserver-xorg-video-radeon 1:7.9.0-1 
  •  xserver-xorg-video-vesa 1:2.3.4-1+b2 
  •  xserver-xorg-video-vmware 1:13.2.1-1+b1"

IMHO, The Deepin developers should hire you after they get the latest driver spec's from Via ;)

My motivation as a developer of OpenChrome graphics stack is to ensure that the code I am involved in developing works with the broadest lineup of VIA Chrome graphics hardware.
I am mainly interested in making sure that the latest upstream code works with your hardware, and while I will like to see old releases of the code to work, there are no fixes for older releases since the latest code can supersede older releases (i.e., If you can compile and run Version 0.3.3, Version 0.6.174 can replace it.).
It is still not clear to me if the latest upstream code works with at least one OS platform, and I feel like I am getting dragged into what I consider unrelated matters such as GRUB boot process.
I have no control over components that run prior to the OS boot process.
Similarly, I have no control over how Linux distributions / xBSD package OpenChrome (or as you pointed out, not packaging at all).
Issues that arise from how the distribution packaged OpenChrome is that particular distribution's issue, and you will have to ask them for help.
If you have other non-bug triage topics to discuss, you will like to post it over at openchrome-users mailing list.


(In reply to Scott from comment #9)
> The ease of switching openchrome-git <=> openchrome in Arch32, is offset by
> the relatively small community/resources. It also introduces an extra level
> of complexity with systemd - nVidia/amdgpu users need to generate an
> initramfs that has the video module. 
> 
> The notebook dual-boots Arch32/NetBSD 7.1.2.  If you're not aware, NetBSD
> provides a monolithic xorg that still uses openchrome 0.3.3 and a modular
> xorg.  Modular xf86-video-openchrome is based on the latest release and does
> not bulk build (I have not tried myself).
> 
> NetBSD 7.1.2 is running fairly well and I suspect that Debian 8/Devuan
> testing will too.
> 
> What I'm mulling over is how much effort to put into future use.  The
> wikipedia entry for Via indicates that they are actively developing cpu's
> capable of competing with AMD for the Chinese market.  Interestingly, the
> Deepin package list does not even provide an openchrome driver
> 
> "•  xserver-common 2:1.19.3-2deepin 
>   •  xserver-xorg 1:7.7+19 
>   •  xserver-xorg-core 2:1.19.3-2deepin 
>   •  xserver-xorg-input-all 1:7.7+19 
>   •  xserver-xorg-input-libinput 0.23.0-2 
>   •  xserver-xorg-input-synaptics 1.9.0-3deepin 
>   •  xserver-xorg-input-wacom 0.34.0-1 
>   •  xserver-xorg-video-all 1:7.7+19 
>   •  xserver-xorg-video-amdgpu 1.3.0-1 
>   •  xserver-xorg-video-ati 1:7.9.0-1 
>   •  xserver-xorg-video-fbdev 1:0.4.4-1+b5 
>   •  xserver-xorg-video-intel 2:2.99.917+git20161206-1+deepin 
>   •  xserver-xorg-video-nouveau 1:1.0.15-2 
>   •  xserver-xorg-video-radeon 1:7.9.0-1 
>   •  xserver-xorg-video-vesa 1:2.3.4-1+b2 
>   •  xserver-xorg-video-vmware 1:13.2.1-1+b1"
> 
> IMHO, The Deepin developers should hire you after they get the latest driver
> spec's from Via ;)

Just to follow up on these two concerning statements.

> Openchrome DDX is working but is relatively unstable.

> It will not run without the /etc/default/grub entry.


In theory, you should not have to tinker /etc/default/grub entry.
At least that's the case with Xubuntu / Lubuntu.
Also, "relatively unstable" is a fairly subjective term, so I do not know what to really think about it.

Scott, a lot of my time got taken for various time consuming tasks this week (the week of May 6th, 2018).
For example, I had to replace my main development computer's (HP 2133 mini-note) SSD which just died after one year of use.
In practice, some other bad things happened as well (non-OpenChrome related), but they are personal, so I will not discuss them here.
I will have limited time to work on OpenChrome for the week of May 13th, 2018, but I will still like to make some progress.
Let me know what you will like to do with the issues you have raised within this bug report.

Kevin,

Thanks for F/U.  I'm willing to try to help but do not want to suffer the same fate as your thin client.  It is currently functional with relatively recent applications in Centos 6.9, NetBSD 7.1.2 and OpenBSD 6.3 and at this point I'm going to leave well enough alone.

Ideally, I would like to get a new notebook and when that happens, I could donate.

Scott, I was recently able to auction off a model similar to the one you got.
When I get a hold of it in the next few days, I will test OpenChrome DDX against it.

On Jul 01, 2018: 23:57, bugzilla-daemon@freedesktop.org wrote:

I will be changing from NetBSD on my 1502NC in the future but I have not
decided what to replace it with.  Will follow your development prior to
making a decision.

>Comment # 14 on bug 106298 from Kevin Brace
>
>Scott, I was recently able to auction off a model similar to the one you got.
>When I get a hold of it in the next few days, I will test OpenChrome DDX
>against it.
>
>━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
>You are receiving this mail because:
>
>  • You reported the bug.
>

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/openchrome/old-bug-database/issues/24.