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
_______________________________________________
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel
