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

Sat Feb 2 22:40:47 PST 2008

> -----Original Message-----
> From: xorg-bounces at lists.freedesktop.org
> [mailto:xorg-bounces at lists.freedesktop.org] On Behalf Of
> pcpa at mandriva.com.br
> Sent: Sunday, February 03, 2008 5:50 AM
> To: xorg at lists.freedesktop.org
> Subject: Re: Issues in current VESA driver.Color distortion when switch VT.
> 
> 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
>
Thanks for your confirm.

> 
> > 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/ve
> sa/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.
> 

VESA driver is important for me and I use it as fallback mode very much. It is so robust that I can't feel it exists here. So when I met a problem, I'd like to make it be fixed. Can you or have someone to review the patch and check in it? Thanks!

The mode's VGA compatibility attribute's seems to be added in VBE2.0, it was made in 2004, about 4 years after your initial version driver. AT that time, Warcraft is popular :)

Anyway, thanks for the vesa driver, thank you!

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