[Openchrome-devel] Testing Openchrome 0.5.178 on VX800

Fri Jan 13 22:21:13 UTC 2017

Hi Sebastian,

> Date: Thu, 12 Jan 2017 03:31:32 +0100
> From: Svenska <svenska-ml at arcor.de>
> To: openchrome-devel at lists.freedesktop.org
> Subject: Re: [Openchrome-devel] Testing Openchrome 0.5.178 on VX800
> Message-ID: <803770e8-3951-7030-f81d-637a823ceafa at arcor.de>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Hi Kevin,
> 
> > 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.
> 
> I did not compile vesafb into the kernel, so I don't know if this is 
> still a problem with newer kernels. Also, I did not enable viafb.
> 

Okay.
I had someone else in the past (several month ago) who told me that if viafb was not installed, his K8M800 chipset based laptop did not boot correctly.
I will have to figure out how to handle this situation since I only use stock Ubuntu / Xubuntu / Lubuntu for testing.

> Different drivers use different conventions. Previous names I have seen 
> were DFP, DVP, DISP, LCD, TTLLCD and maybe others which I don't remember 
> right now. FP was obvious, but new to me. :-)
> 

It was all over the place, so I picked FP.
LVDS is not a good name since it means the signaling technique used for high speed signals.

> > This is likely due to the code to recognize the integrated TMDS
> > transmitter for DVI present in CX700 / VX700 chipset doing its work.
> 
> Yes, the logs indicate exactly that. If there is no reliable way to 
> detect a DVI connector on those chipsets, then the current solution is 
> very much preferable.
> 

For now, I will leave it there.

> >> After connecting a VGA screen and running "xrandr" without
> >> arguments, the external screen comes alive while the internal
> >> display immediately fades to white.
> >
> > White screen really means that OpenChrome is setting an illegal (out
> > of range) resolution for the panel.
> 
> Having the screen fade to white happens whenever Openchrome changes the 
> LCD resolution. If everything succeeds, the screen comes back to life 
> after a second or so. This also happens at boot time (as in the sequence 
> "kernel text mode", "black screen", "fade to white", "desktop 
> background"). I don't know if this is expected behaviour.
> 

Does the FP reach the desired state (i.e., proper screen display) after a second or two?
Yes, it is perfectly possible for the screen to flicker when you change the screen mode since I have not invested much in reducing screen change flicker, but if the screen stays white (it is really bright white) for a long time, that is a problem.
That means OpenChrome is feeding out of range signal to the FP.

> >> Unfortunately, scaling, rotation or other transformations do not
> >> work on either screen (xrandr returns "Configure crtc 1 failed" (or
> >> crtc 0 for VGA).
> >
> > There is no support for hardware rotation at this point. [...]
> > Again, scaling is also a very low priority
> > item at this point as well.
> 
> I know that, but maybe I hoped that by setting a flag in the driver, at 
> least software-based scaling could be made to work. But if it's not 
> possible, then I have to live without. I did try to get Xephyr to do 
> scaling in a nested fashion, but couldn't get this to work either. 
> Rotation would have been nice to have, but isn't really important.
> 

In terms of OpenChrome DDX development priority, this is what I have got.

1) Organize OpenChrome DDX code further
2) Rewrite FP code further
3) Add VX900 chipset HDMI support by backporting it from drm-openchrome (the next generation OpenChrome DRM with KMS support)
4) Rewrite TV output code (i.e., VT1622, VT1623, VT1625, etc)

Adding scaling support will have to be fifth priority at this point.
I will still consider it eventually since you asked and there are some left over code from the past.
Rotation support is definitely below TV output and scaling support.

> > 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.
> 
> I will test this and report back.
> 
> >> 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.
> 
> It works well enough for the common use case, and the attached Via CPUs 
> become less and less useful for video playback anyway.
> 

Yeah, Xv stuff is also a low priority at this point since the code still has many pressing needs here and there.
Eventually I will get to it since I will have to do something with it when I work on drm-openchrome.

> >> 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.
> 
> In my case, viafb is not enabled in the kernel. Also, power management 
> never worked on my machine, not even in Windows. By now, the battery is 
> basically dead.
> 

I do perform tests on standby resume fairly often, but certainly not all the configurations are working.
For example, it works well with HP 2133 Mini-Note + Xubuntu 14.04.
But for HP 2133 Mini-Note or Epic 1314 and Lubuntu 10.04 or 12.04, mouse cursor gets lost when resuming.
For CLE266 and KM400 chipsets, it will freeze when resuming on Ubuntu / Lubuntu 10.04.
For g netbook, resume works most of the time on Lubuntu 12.04.
What I discovered in the development process with this issue is that past OpenChrome developers were relying on the VGA BIOS / viafb to set many register bits for proper operation.
The current OpenChrome sets more of the registers inside OpenChrome, and this has somewhat improved the resume behavior since FP is much harder to get it right when standby resume is involved. (i.e., VGA only is not that hard to handle)
If the code is assuming that someone else (i.e., VGA BIOS / viafb) to set up the FP correctly, it is very likely to not work when resuming from standby since it appears that many FP related registers get corrupted when resuming.

> >> 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.
> 
> They are very much deserved. ;-)
> 

Well, here in the United States, when a retail store is sold to a new owner, there often is a sign displayed on the storefront by the new owner that says, "Under New Management."
I have already criticized the past developers enough in Year 2016 that I do not do it too often anymore, but yes, OpenChrome is under new management (i.e., me), and I think I am far more concerned about stability and reliability of the device driver than the past developers.
>From my own experience of observing the computer industry for many years, FOSS based OSes still lag considerably when it comes to its out of the box user experience.
I think a lot of this has to do with device driver stability more than anything else.
I am trying to get OpenChrome to have comparable reliability to what a typical Windows graphics device driver has, and I still have to work further to get to that level.

> > 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.
> 
> I have not tested the DRM/KMS support at all, assuming that the UMS path 
> is still the better option.
> 

Yes, for everyday use, you should stick to the existing OpenChrome DDX only since drm-openchrome still has number of usability issues.
One is the aforementioned bug that crashes the X.Org Server when the screen resolution is changed during runtime.
I still have not resolved this issue. (It is a very high priority.)
Another one is, 2D acceleration does not work with UniChrome (KM400 chipset) or later Chrome9. (VX900 chipset)
That being said, for VN896 chipset (early Chrome9), OpenChrome DDX + drm-openchrome gets usable 2D rendering performance on Xubuntu 14.04.
It is good enough to the point where I can use it for actual software development.
OpenChrome DDX's UMS code is far more tested and repaired at this point than drm-openchrome.
Besides, you need to compile drm-openchrome which is basically compiling Linux kernel, and this easily takes half a day or more and close to 10 GB of storage.

> By the way, if there was a working KMS driver, what advantages would the 
> X Openchrome driver bring, compared to the X Modesetting driver?
> 

If I understand the situation correctly from reading Phoronix articles, we still need OpenGL 2.0 support for Glamor
Without Glamor, xf86-video-modesetting does not work.
Also, only Chrome9 can handle OpenGL 2.0.
I think Chrome9 is really comparable to Intel 915 or 945 chipset's IGP.
I have not even thought about working on the 3D stuff considering that I still have not been able to stabilize drm-openchrome. (i.e., aforementioned runtime mode setting crash)
I think getting drm-openchrome mainlined with the latest Linux kernel will have higher priority than worrying about 3D at this point.
I think I will start working on the 3D at some point in a few years.
Getting the code mainlined is actually really hard since I will like to get all the devices (i.e., CLE266 chipset all the way to VX900 chipset) to work out of box comparable to where OpenChrome DDX UMS code is now.
Compiling and installing drm-openchrome takes far more time than OpenChrome DDX, so my development progress is far slower due to the way the compilation script is written for the Linux kernel.
That being said, I have found ways to shorten the compilation and installation time to about 30 minutes for drm-openchrome.
For OpenChrome DDX, this is more like 4 minutes.

> > 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.
> 
> I remember watching a talk by Luc on KMS and modesetting, where he 
> stated that modesetting is surprisingly hard to get right and completely 
> underestimated by users.
> 

Yeah, Luc likes to scold me from time to time.

https://lists.freedesktop.org/archives/openchrome-devel/2017-January/003120.html

He is probably correct that mode setting is hard to get it right, and it is especially hard when the chip manufacturer did not make all the relevant documents public (i.e., CLE266 graphics programming guide, UniChrome Pro graphics programming guide, early Chrome9 graphics programming guide, chipset motherboard design guide, etc.) or has never made them public. (i.e., NVIDIA)
I will also say that employers think that only valuable graphics programmers are the ones who deal with the 3D graphics portion, and I will not be surprised that if they think that the type of work I am doing (i.e., mode setting code development and testing) can be done by *ANY* programmer off the street.

> > 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.
> 
> I don't have an account there yet, but I can do this.
> 

Okay, I look forward to it.

> Again, thanks for your work!
> 
> Best Regards,
> Sebastian
> 
> 

Go ahead and try Version 0.5.181.
It fixes the 2040 / 2048 dot horizontal direction issues you reported.
I have sort of have known that issue for a while, but did not bother to fix it since I was a little lazy on that issue.
You complained about it (that's okay), so I went ahead and fixed it by restricting the screen to 2044 dots for 32-bit color mode.
I tried 2048 dots, but I could not get the hardware to cooperate. (i.e., right side screen will get messed up)
If you use 16-bit color mode, you can use up to 4088 dots, but I will admit that 16-bit color mode has some color tone issues. (a little weird color tone can be observed with some OSes like Lubuntu 12.04)
8-bit color (probably no one uses it at this point) does not work correctly at all at this point. (color gets totally messed up)

Regards,

Kevin Brace
The OpenChrome Project maintainer / developer