[Openchrome-devel] Testing Openchrome 0.5.178 on VX800

[Svenska]

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