[Openchrome-devel] Testing Openchrome 0.5.178 on VX800

[Svenska]

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.

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

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. :-)

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

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.

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

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

A bit more annoying is that Openchrome apparently tries to do 
"something" before failing, leaving the screen fading out to white 
again. Changing to a virtual console and back fixes the problem.

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

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

>> 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. ;-)

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

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

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

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

Again, thanks for your work!

Best Regards,
Sebastian