[Openchrome-devel] [Bug 106326] openchrome git failed on xubuntu 18.04

[bugzilla-daemon at freedesktop.org]

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

--- Comment #12 from Kevin Brace <kevinbrace at gmx.com> ---
sebastien, thank you for the before and after register dump.
It was very helpful in understanding the underlying hardware configuration
Samsung used.
It appears that Samsung hooked up LVDS2 (LVDS channel 2) to the FP rather than
the more logical LVDS1.
I think I will need to use quirk code to handle this special case.
As for why OpenChrome DDX works with a VGA monitor attached, LVDS2 happens to
have IGA2 (think of it as display controller #2) selected as its display source
(very likely set by the VGA BIOS), although the current code "thinks" LVDS1 has
the FP connected.
The current code is setting everything right except LVDS2 since it thinks LVDS1
has the FP attached.
When VGA and FP are both used simultaneously, X Server almost always assigns
VGA to IGA1 and FP to IGA2.
If you only use FP, it assigns FP to IGA1, but the VGA BIOS appears to be
setting IGA2 as LVDS2's display source, hence, you do not see anything on the
screen because IGA2 is not in use.
    Ever since I got involved in developing OpenChrome graphics stack (starting
roughly 3 years ago), I have extensively rewritten display mode setting code.
What the previous developers did not do very well is to proactively assign
display source for the display output type used by the end user.
It was almost always relying on VGA BIOS to set this (essentially relying on
"left over" register bits), but the problem with this approach is that it just
cannot handle standby resume since the register bits get erased when coming out
of standby.
Although I myself did not handle your case correctly in your situation due to
lack of having the actual hardware in front of me, I now think I know what is
going on, and all I will have to do is to write you a small patch that handles
Samsung NC20 netbook as a special case.
For this, I will need lspci dump to figure out the PCI subvendor ID and
subdevice ID.

lspci -vvnn > Samsung_NC20_lspci_dump.txt

I do not personally like this approach, but I already do this for Sylvania g
netbook (VX700 chipset) and Quanta IL1 netbook (VX800 chipset), so I do not
mind doing it for another hardware.
OpenChrome used to have a huge table (close to 300 entry) of known devices to
handle this, but it was not well designed (cannot really handle your situation
anyway), was a maintenance nightmare, and the approach is contrary to a good
graphics device driver programming practice, so I got rid of it.

https://cgit.freedesktop.org/openchrome/xf86-video-openchrome/commit/?id=9822064f0cf2675fbaa1390b86a83e5bdd61fbf2

There were a few side effects doing this, but as far as I know, almost all
issues are now resolved, and I think OpenChrome handles mode setting far better
today, especially standby resume.
So please provide me with the lspci dump and upload the data.
It will take a day or two for the patch to be ready.
When the patch is ready, I will give you how to test OpenChrome DDX with the
patch applied.
    If the code works, I will obviously commit the code into the OpenChrome DDX
upstream repository, but variant of the code will also make it into the
upcoming OpenChrome DRM.
OpenChrome DRM will finally support KMS (Kernel Mode Setting), and considering
the lack of corporate financial backing of OpenChrome Project (several Nouveau
developers work for RedHat, one works for Intel, but uses his spare time on it,
etc.), I think this is quite an achievement.
I wrote this reply on a pretty buggy KN400 chipset laptop (Averatec 3250) with
OpenChrome DRM performing KMS.
I got Lubuntu 18.04 and Firefox 52 ESR (Extended Service Release) running on
this laptop (AMD Athlon XP does not support SSE2 instruction, hence, I need to
use Firefox 52), with two displays running (FP + VGA).
I also figured out how to get standby resume working on this really buggy
laptop (the laptop itself is not that bad hardware wise, but standby related
part of ACPI BIOS is broken, however, I found a workaround that allows me to
enter / exit standby fairly reliably).
I am trying to get OpenChrome DRM to work as reliably as the existing legacy
OpenChrome DDX's mode setting code (UMS or User Mode Setting), so any help I
can get in improving the reliability of OpenChrome is appreciated.


(In reply to sebastien from comment #11)
> ok I join dump log before and after standbye
> 
> My netbook doesn't work without vga branched with latest git version.
> With vga screen branched, flat panel and vga work before standbye
> After standbye only vga work

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/openchrome-devel/attachments/20180504/d1c476f5/attachment.html>