[Openchrome-devel] Testing Openchrome 0.5.178 on VX800

[Kevin Brace]

Hi Sebastian,

> Date: Wed, 11 Jan 2017 05:53:57 +0100
> From: Svenska <svenska-ml at arcor.de>
> To: openchrome-devel at lists.freedesktop.org
> Subject: [Openchrome-devel] Testing Openchrome 0.5.178 on VX800
> Message-ID: <b942cb14-bddf-9992-51c9-9f17bb87d248 at arcor.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi,
> 
> I have tested a recent version of Openchrome (0.5.178) on my "One A110" 
> netbook (Quanta IL1, VX800) again, without any xorg.conf, on a Debian 
> stretch/testing and a self-made kernel 4.9.1.
> 

Yes, thank you very much for trying the latest version.
I had several people complaining about Linux 4.5 kernel having issues with OpenChrome, but I guess you did not encounter that bug.
It is a bug where vesafb gets loaded before OpenChrome, and it maps the frame buffer, so OpenChrome fails when it also tries to map the frame buffer.
The workaround if you ever encounter it is to blacklist vesafb.


> The internal display is correctly detected as FP-1 (older versions used 
> LVDS-1) and works fine without an external screen connected. The VGA 
> connector is correctly detected as VGA-1.

Yes, I changed the naming convention since not all flat panels are connected via LVDS based FP interface.
I find FP (Flat Panel) to be the more appropriate term to be used in this content.


> Also, a disconnected DVI-1 
> interface is shown (there is no DVI connector on this device).

This is likely due to the code to recognize the integrated TMDS transmitter for DVI present in CX700 / VX700 chipset doing its work.
According to VIA Embedded's EPIA-M800 mainboard information page, VX800 does appear to actually have integrated TMDS transmitter needed to support DVI.

http://www.viatech.com/en/support/eol/epia-m800-eol/
https://cdn.viaembedded.com/eol_products/docs/epia-m800/datasheet/VIA+EPIA-M800_datasheet_v120213.pdf

I made extensive code improvements to support CX700 / VX700 integrated TMDS transmitter for OpenChrome Version 0.6.
It is detecting a DVI connector availability based on a flag bit that James Simmons (past developer of OpenChrome who did most of drm-openchrome development) was using.
This bit is set by VGA BIOS, so it is not a hardware based detection solution.
There is also a thing called pin strapping, but it appears to be less than reliable way to detect LVDS / TMDS availability for CX700 / VX700 / VX800 / VX855 / VX900 chipsets.
    The major difference between OpenChrome Version 0.5 and eventual Version 0.6 is the integrated TMDS transmitter DVI support.
Yes, this thing has somehow worked for a while, but it had number of issues, so I spent a lot of my time resources between July to September 2016 to really fix it.
For this, I obtained a netbook called g netbook which is really based on VIA Technologies NanoBook reference design.
This one has VX700 chipset with a 800 x 480 non-I2C panel.
I have already verified that FP and DVI can work simultaneously as well as FP and VGA.
    Regarding Quanta IL1, I was able to obtain its mainboard schematic, and interestingly, it is connecting LVTTL interface FP to DVP1 (Digital Video Port 1); it is not using its integrated LVDS interface for FP.
This is a very unusual implementation.
It does complicate OpenChrome development since I never dreamed that this type of arrangement was even allowed.


> For the 
> internal display, only the native resolution of 800x480 is shown by 
> Xrandr. This is okay, but breaks some application trying to change to 
> the standard 640x480 resolution (mainly games and DOSBox). (Older 
> versions of Openchrome used to show 800x480, 720x480 and 640x480.)
> 

This is the case due to OpenChrome Version 0.3.0 or later disabling panel scaling code.
If you go back to Version 0.2.906, you will notice that even if you are using a flat panel, you can select different screen resolutions.
I did not make the decision to do this.


> After connecting a VGA screen and running "xrandr" without arguments, 
> the external screen comes alive while the internal display immediately 
> fades to white.

Yeah, that does not sound good.
I usually use ARandR for screen resolution testing.
I tested various screen arrangements using ARandR (i.e., left - right, top - bottom, right - left, bottom - top, etc.), so I am surprised that white screen is happening with the panel.
White screen really means that OpenChrome is setting an illegal (out of range) resolution for the panel.


> Switching to a virtual console and back fixes this; this 
> happens whenever Openchrome reconfigures both screens. This is an 
> important regression compared to version 0.4.0.
> 

I do not have access to my g netbook for another 3 weeks, but when I get access to it again, I will try to use xrandr to see if I can reproduce the bug.


> Xrandr reports a maximum screen size of 2048x2048. However, enabling X 
> coordinates larger than 2040 leads to corruption (no crash). Both 
> panning and multi-monitoring work fine as long as the total screen width 
> does not exceed 2040. Even partly overlapping configurations work fine.
> 

I have been aware of this bug to some extent, but I have not spent that much time analyzing why this was occurring.
I may try a trick the past developers were using where the horizontal direction (x direction) fetch count for the display register is set to "calculated value + 1."
This might fix the bug.
I will try to come up with a patch for this since this is not that hard to do.


> Unfortunately, scaling, rotation or other transformations do not work on 
> either screen (xrandr returns "Configure crtc 1 failed" (or crtc 0 for 
> VGA). I am really missing support for scaling, since it would make 
> dealing with quite many applications easier. (The Windows driver allows 
> up to 1024x768 on the internal display, making e.g. the VLC settings 
> screen fit on the display.)
> 

There is no support for hardware rotation at this point.
I hate to say this, but rotation has the lowest development priority at this point since OpenChrome DDX still contains far more pressing issues that I need to tackle.
Again, scaling is also a very low priority item at this point as well.


> The virtual console is not shown on a VGA screen (no signal), and is 
> unusable on the internal display if a VGA screen is connected and has 
> been detected by Openchrome. This is true even after turning it off 
> manually. After unplugging, the virtual console becomes usable again.
> 

I made an important bug fix related to VT (Virtual Terminal) with Version 0.5.179.
You may want to try this to see if the VT behavior is better.
If you boot the computer with the VGA cable disconnected and hotplug it later after the OS has finished booting, you typically will not get VT to display anything when you switch to it.
If you want simultaneous VT on FP and VGA, you need to have VGA connected at the time of OS boot.
Also, with newer Linux kernels (i.e., around 3.19 or later), it appears that VGA will display portions of the screen FP is displaying in VT mode.
Sometimes, if you type a lot of stuff on the command line, the VGA screen may display portions of it.
The behavior of VT really varies with the Linux kernel version.
This might be because some other developers were tinkering with via fb device driver outside of the OpenChrome Project.
There appears that some commits were made between 2012 to 2014, and maybe the VT behavior is different as a result.


> XVideo only works on a single screen (the internal display if it is 
> active, VGA if it is not).

I have not touched the Xv code since I have been a developer.
Only one small log message was changed recently, and I was not the author of it.


> ACPI standby crashes the whole machine, with 
> the display fading to white.

Yeah, the possible cause of it is the via frame buffer device driver doing something weird when resuming from ACPI S3 State.
It appears that some crucial mailbox registers set by VGA BIOS (this is VIA Technologies proprietary stuff, and not related to the "original" VGA BIOS or VBE defined by VESA) get corrupted when resuming from standby.
The problem with your model (Quanta IL1) is that the panel used is a type that does not have I2C to read off EDID for panel detection.
Hence, the mailbox registers set by VGA BIOS is the only way to detect its panel resolution.
When these registers get corrupted, then OpenChrome sets the wrong CRTC parameters, hence the white screen.
g netbook has the same exact issue, and I do have a few less than desirable tricks I can think of to retain these mailbox registers in question.
I can come up with a patch for this if you can file a bug report with https://bugs.freedesktop.org.


> DPMS seems to work well.
> 

I did test monitor / panel shut off, including backlight turn off.


> Compared to version 0.4.0, Openchrome feels much more stable. It did not 
> crash throughout my testing, and switching to the virtual console fixed 
> most modesetting bugs. Thank you very much for your work!
> 

Thank you very much for the compliments.
Between Version 0.4.0 and Version 0.5, I fixed the runtime screen resolution change crash bug that James Simmons apparently introduced accidentally around Version 0.3.2.
Unfortunately, runtime screen resolution change feature still does not work with the next generation OpenChrome DRM (OpenChrome DRM with KMS support. AKA drm-openchrome), and this is one of the major bug I have yet to fix.
Other than that, I am able to get HP 2133 Mini-Note and Epic 1314 to work with Xubuntu 14.04.0 LTS and drm-openchrome.
    All the development efforts for the past 1.5 years have been around display detection (and a little bit of drm-openchrome stuff related to display detection as well), and it is far harder than I originally imagined.
Even Intel broke their Atom SoC's flat panel code (i.e., Intel "Bay Trail" $60 USD Windows 8.1 with Bing tablets they were selling back in 2014. I recently bought a second one for $46 USD to install Ubuntu 16.04 LTS, but I was disappointed to learn that Intel broke the Bay Trail FP detection code in 2014 or so . . . I still have not succeeded in this project.) and apparently it is still broken . . .


> If I may wish for a single thing, it would be support for scaling on the 
> internal display. Everything else works well enough for my needs.
> 

James left some code for scaling inside drm-openchrome.
I do not plan to remove the code, and it is possible that I may be able to backport some of it to OpenChrome DDX down the road.
His scaling code implementation appears better than the way OpenChrome DDX developers did.


> I hope I am not annoying you by posting these mails every once in a 
> while. :-)
> 
> Best Regards,
> Sebastian
> 
> 

Sebastian, no, you are not annoying me, but I think the bugs you are reporting are serious enough that you may want to file a bug report with http://bugs.freedesktop.org.
I may want to fix one or two bugs you are reporting prior to Version 0.6 release.
The freedesktop.org bugzilla interface makes it easier to post a patch, so it will be nice if you can file a bug report there.

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer