[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#403556: xserver-xorg-video-mga: VT switch dims 16-bit-color screen 0 when screen 1 is 24-bit



Kalle Olavi Niemitalo <kon@iki.fi> writes:

> Being unable to define different screens is a problem because it
> makes xsm (of x11-utils 7.3+1) divide its window halfway between
> the two monitors.

That is actually x11-session-utils 7.3+1.

> - The DoubleScan flag seems to be ignored on the VGA2 output.
>   I am not entirely sure it worked in the previous version either.
>   However, the same mode works correctly on the VGA1 output.

I looked in xserver-xorg-video-mga_1.4.4.dfsg.1.orig.tar.gz
and it seems to ignore the V_DBLSCAN flag on the second CRTC
too.  Perhaps the hardware doesn't support that feature?
However, in xserver-xorg-video-mga-1.9.100.dfsg.1/mga_driver.c,
MGAPreInit does this:

    clockRanges->interlaceAllowed = !pMga->SecondCrtc;
    clockRanges->doubleScanAllowed = TRUE;

If doublescan were not possible on the second CRTC, presumably
this would check pMga->SecondCrtc on the second line too?

> - I don't get a mouse cursor on the second monitor.  At first I
>   thought it might be some presentation feature, activated when
>   the monitors are displaying the same picture otherwise.
>   However it also happens when they are configured side by side.

In both versions, MGAGUseHWCursor in mga_dacG.c does:

    if( pMga->SecondCrtc == TRUE )
        return FALSE;

In 1.4.4.dfsg.1, MGAPreInitMergedFB used to set pMga->SecondCrtc
= TRUE.  This code has apparently been removed from
1.9.100.dfsg.1; pMga->SecondCrtc is now always FALSE.
I presume MGAGUseHWCursor should now be somehow hooked to
crtc_mode_set in mga_g_crtc2.c, so that it begins returning
FALSE when the second CRTC is turned on.

Attachment: pgpvYfUploFXE.pgp
Description: PGP signature


Reply to: