Issues in current VESA driver.Color distortion when switch VT.
pcpa at mandriva.com.br
pcpa at mandriva.com.br
Sat Feb 2 13:50:07 PST 2008
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
More information about the xorg
mailing list