Hi,
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.
On my system, viafb messes up the display (fade to white) unless I add
many module parameters. So I didn't compile it into my kernel either.
Only xf86-video-vesa and xf86-video-openchrome exist.
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?
If the xrandr call succeeds, the display starts to fade, but after a
second or so it reaches the desired state and everything is fine afterwards.
If the xrandr call fails (e.g. specifying scaling or rotation), then the
screen fades out to white and stays white.
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.
I remember the same discussions (as in, punch registers or rely on the
VBIOS) about radeon, and nouveau strictly relies on NVidia-provided and
signed firmware for new devices. As far as Openchrome goes, relying on
the BIOS may have been the better (or even the right) choice back then,
and hindsight is always 20/20.
Yes, for everyday use, you should stick to the existing OpenChrome
DDX only since drm-openchrome still has number of usability issues.
Okay.
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.
I have used the modesetting driver on embedded systems lacking a GPU
(i.e. with only a dumb framebuffer), so it definitely does not require
anything beyond a basic KMS driver. The DRM driver should support
xf86-video-modesetting out of the box.
However, I don't know if it is possible to implement any meaningful 2D
or video acceleration within the DRM driver. The modesetting driver
can't provide either without Glamour support.
Also, only Chrome9 can handle OpenGL 2.0. I think Chrome9 is
really comparable to Intel 915 or 945 chipset's IGP.
I don't think there will be any stable 3D support for Chrome9 ever. The
3D support is not even useful on Windows (it barely suffices for Aero
Glass on Windows 7), and even the binary drivers are prone to crashing.
>>> 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.
>
Go ahead and try Version 0.5.181. It fixes the 2040 / 2048 dot
horizontal direction issues you reported.
Interestingly, in 32-bit mode, both 2044 and 2048 pixels gave me FP
corruption on the old driver. With the new driver, the 2044 pixel wide
mode works. So this is fixed, thank you!
In 16-bit color depth, both 4088 and 4096 used to give corruption, while
4088 pixel wide screen works fine now.
Setting an unaligned size (e.g. 4082x4096) often crashes the driver,
with Xorg.0.log containing:
> Linear memory allocation failed
> DRM memory allocation failed -12
> (Backtrace)
> Segmentation Fault
This is not always immediately reproducable.
Even with a VGA screen connected, the virtual terminal stays usable. So
you fixed that bug as well, thank you!
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)
I checked, and on my system, using Xfce4, it works correctly. It is just
that modern toolkits require far more than the available 256 colors and
do handle 8-bit color anymore (e.g. no dithering). So it looks just
really bad, but is not broken.
Also, if it is really messed up in your system, you may have per-window
color palettes. In this case, all colors on the screen are plainly
wrong, except for the currently active window. Selecting a different
window then changes all colors on the screen.
>>> 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.
Something is fishy with freedesktop.org.
I constantly receive emails from bugzilla to my address, but I don't
have any login data, and requests for a "password reset token" never
arrive. Since I can't login to bugzilla, I can't even opt-out from those
messages.
Very strange indeed.
Best Regards,
Sebastian
_______________________________________________
Openchrome-devel mailing list
Openchrome-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/openchrome-devel
