Re: cyblafb in kernel 2.6.16: corrupted display in Xfree86

[Thomas Arendsen Hein <thomas@intevation.de>]

* Knut Petersen <Knut_Petersen@t-online.de> [20060323 18:07]:
> Thomas Arendsen Hein schrieb:
> 
> >With /sbin/modprobe cyblafb && /usr/sbin/fbset -a 1152x864-70 -depth 16
> >(changing fb.modes would probably help, too) everything is back to
> >normal for me.
>
> So the problem is that the 8bpp modes do not work with the
> X framebuffer driver. Please report that bug, I think X is responsible.

But why did it work up to 2.6.15.6 then?
I know for sure that I had 8bpp in fb console and 16bpp in X.

> >>Is there a special reason not to use the X* trident driver?
> >
> >Yes, I had crashes when using more than one X display (e.g. one
> >local xdm and one "X -query other :1"), 
>
> Try it again, the recent cyblafb works around X and xdm bugs
> that could have caused that crashes.

No, I had crashes with non-fb console and trident X driver.

I never tested if cyblafb console and trident X have problems.

> >and switching between X and
> >console is _much_ faster this way.
>
> I doubt that ... switching between X trident and cyblafb and back again
> takes only a few miliseconds here.

Maybe I had little variations in the monitor timings which caused
the monitor to re-sync. With X on cyblafb this is obviously always
identical.


I've found another problem with the new cyblafb under X which didn't
happen before: DPMS no longer turns of the monitor. At the time
where DPMS suspend kicked in before, now the xlock clock simply
stops updating, but is still visible (xlock -mode dclock).

Thomas

-- 
Email: thomas@intevation.de
http://intevation.de/~thomas/


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642