Issues in current VESA driver.Color distortion when switch VT.

[pcpa at mandriva.com.br]

Quoting "Liu, Wolke" <Wolke.Liu at amd.com>:

> Hi all,

  Hi,

> Here is the bug I found in current vesa driver, could you have a look 
> and give some advice? 3 patches are list in this mail, if ok, who can 
> help to check in them to git depot?
>
> 1. Logic error
> 	As mentioned in another mail, this bug will cause color distortion 
> in 8bpp when switch VT.
> 	Here is the fix:
>
> diff --git a/src/vesa.c b/src/vesa.c
> index e4e6547..57ca3a7 100644
> --- a/src/vesa.c
> +++ b/src/vesa.c
> @@ -1169,7 +1169,7 @@ VESASetMode(ScrnInfoPtr pScrn, DisplayModePtr pMode)
>        VBESetLogicalScanline(pVesa->pVbe, pScrn->displayWidth);
>
>     if (pScrn->bitsPerPixel == 8 && pVesa->vbeInfo->Capabilities[0] & 0x01 &&
> -        !(data->data->MemoryModel & 0x6 || data->data->MemoryModel & 0x7))
> +        !(data->data->MemoryModel == 0x6 || data->data->MemoryModel == 0x7))
>        VBESetGetDACPaletteFormat(pVesa->pVbe, 8);
>
>     pScrn->vtSema = TRUE;

  I think it is a bug; 6 and 7 aren't a power of two...
  It seens to to be just the wrong operator. This was added in commit
3b07dd7f43be7c1263f80eb279605a89c860dc4b


> 2. Access VGA registers when in a non VGA compatible mode
> 　　This is conflict to VBE spec. I got color corruption when 
> switch VT. In fact, it may have other side effect. Please see
> 　　http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/drivers/vesa/vesa.c.diff?r1=text&tr1=1.47&r2=text&tr2=1.46&diff_format=l
>
>      A.  Handle screen blanking in the vesa driver for non-VGA 
> compatible modes  (David Dawes).
>
> diff -u -r1.46 -r1.47
> --- xc/programs/Xserver/hw/xfree86/drivers/vesa/vesa.c	2005/02/11 
> 19:45:57	1.46
> +++ xc/programs/Xserver/hw/xfree86/drivers/vesa/vesa.c	2005/02/26 
> 03:18:38	1.47
>
> @@ -1518,6 +1524,18 @@
>     ScrnInfoPtr pScrn = xf86Screens[pScreen->myNum];
>     VESAPtr pVesa = VESAGetRec(pScrn);
>     Bool on = xf86IsUnblank(mode);
> +    VbeModeInfoBlock *vMode;
> +
> +    if (pScrn->currentMode) {
> +	vMode = ((VbeModeInfoData*)pScrn->currentMode->Private)->data;
> +	/*
> +	 * Don't try to use VGA blanking for modes that are not
> +	 * VGA-compatible.
> +	 */
> +	if (vMode->ModeAttributes & (1 << 5)) {
> +	    return FALSE;
> +	}
> +    }
>
>     if (on)
> 	SetTimeSinceLastInputEvent();
>
> Though my cards works well without above patch, I think this patch is needed.
> 　
> 　　B. the same root cause will affect palette too in 
> VESALoadPalette(), it will cause color distortion now.
> diff --git a/src/vesa.c b/src/vesa.c
> index e4e6547..dbb70bc 100644
> --- a/src/vesa.c
> +++ b/src/vesa.c
> @@ -1335,7 +1335,10 @@ VESALoadPalette(ScrnInfoPtr pScrn, int 
> numColors, int *indices,
> {
>     VESAPtr pVesa = VESAGetRec(pScrn);
>     int i, idx;
> +   VbeModeInfoBlock *data = 
> ((VbeModeInfoData*)(pScrn->currentMode->Private))->data;
>
> +    if (data->ModeAttributes & 0x20)
> +        return;
> #if 0
>
>     /* This code works, but is very slow for programs that use it 
> intensively */
> 　　
> 　　This fix is workable. Only the mode is VGA compatible, we can 
> reload the palette via RAMDAC register.
> 　　If is not a VGA compatible mode, in fact, we should use the 
> commented git code. But this method will cause color distortion in 
> some card. The reason is the system palette table is different to 
> different hardware palette.  I have compared NV17 and RV620 card, 
> they are different. There are codes in the git driver folders that 
> contain the converting algorithm for different chips. So it beyond 
> the vesa driver's capability that to convert system palette to 
> correct H/W palette format. I just jump over it and use the default 
> H/W palette. Most cards will use the default h/w palette after set 
> mode. It works on my cards, but I am not sure it will affect others.

  To tell you the truth, I made that change in 2000, in one of the
original vesa driver versions, so I could use wine to play Starcraft :-)

> The long history of VESA driver beyond my knowledge, please correct 
> me. Thanks for you attention.

  Originally, I wrote it as an attempt to have XFree86 starting with
as low chances of failure as possible, and I was just experimenting
with some possible alternative to the vga driver, so that xf86cfg
(aka xorgcfg) would not be a complete failure :-)

  It was also meant to be a fallback mode, until a working driver was
built for newer cards. But really, I wrote it in a few days back in
2000 and never looked much at it again.

> Regards,
> Wolke
>
>
> _______________________________________________
> xorg mailing list
> xorg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xorg

Paulo