Re: 4.4.99.903: s3: missing some of the screen

David Dawes <[email protected]>
Newsgroups gmane.comp.xfree86.devel
Message-ID <[email protected]>
On Tue, Mar 15, 2005 at 12:37:28PM +0100, N?meth M?rton wrote:
>David Dawes wrote:
>>On Mon, Mar 14, 2005 at 08:45:07PM +0100, N?meth M?rton wrote:
>>
>>>Marc Aurele La France ?rta:
>>>
>>>>On Fri, 11 Mar 2005, [ISO-8859-2] N?meth M?rton wrote:
>>>>
>>>>
>>>>>Starting XFree86 4.4.99.903 using the s3 driver at mode 1024x768 8bpp 
>>>>>I see the following screen:
>>>>
>>>>
>>>>>   0     303                   1023
>>>>>   |      |                      |
>>>>>0 ---BBBBBBBB----------------------+
>>>>>   BBBBBBBB                      |
>>>>>   BBBBBBBB                      |
>>>>>   BBBBBBBB       GOOD AREA      |
>>>>>   BBBBBBBB                      |
>>>>>   BBBBBBBB                      |
>>>>>767--BBBBBBBB----------------------+
>>>>
>>>>
>>>>>where B means that black pixels are displayed always.
>>>>
>>>>
>>>>>I don't know what is the problem exactly but the attached patch 
>>>>>removes this bug. (May cause new ones, too...)
>>>>
>>>>
>>>>>chip:
>>>>>-----
>>>>>S3 Trio64V+
>>>>>P1E3BF
>>>>>86C765
>>>>>9650 MB851
>>>>>TAIWAN
>>>>
>>>>
>>>>>VGA BIOS:
>>>>>---------
>>>>>Phoenix S3 TRIO64V+ Enhanced VGA BIOS. Version 1.02-02
>>>>>Copyright 1987-1992 Phoenix Technologies Ltd.
>>>>>Copyright 1992-1995 S3 Incorporated.
>>>>>All Rights Reserved
>>>>
>>>>
>>>>>lspci -v:
>>>>>---------
>>>>>0000:00:09.0 VGA compatible controller: S3 Inc. 86c764/765 
>>>>>[Trio32/64/64V+] (rev 54) (prog-if 00 [VGA])
>>>>>     Flags: medium devsel, IRQ 10
>>>>>     Memory at e0000000 (32-bit, non-prefetchable) [size=64M]
>>>>
>>>>
>>>>Could you try the attached instead?  This one also fixes a few other 
>>>>problems I noticed.
>>>
>>>The problem is solved if I use the patch.
>>>
>>>Running the xtest 4.0.11 the following tests are failed using 
>>>4.4.99.903+patched s3 driver, using 1024x768 8bpp:
>>>
>>>XListPixmapFormats
>>>XDrawArc
>>>XDrawArcs
>>>XSetFontPath
>>>XAllocNamedColor
>>>XLookupColor
>>>XStringToKeysym
>>
>>
>>XDrawArc and XDrawArcs are expected.
>
>Are these tests bad?

There is an accepted long-standing mis-match between the spec and
the implementations.  My recollection is that an implementation that
matches the spec exactly would require higher precision arithmetic
than is typically available.

>>XSetFontPath might be configuration related.
>
>After installing 
>ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.4.99.903/binaries/Linux-ix86-glibc23/Xf100.tgz 
>optional package and setting the path in /etc/X11/XF86Config the test 
>passed. I cannot find in the xtest 4.0.11 documentation that the 100dpi 
>fonts must installed to pass these tests.

I'll add that to the xtest docs.

>> XStringToKeysym should go away if you run with XKB disabled.
>
>I run the X server as
>
>XFree86 -ac -s 0 -kb -dpms
>
>so the -kb disables the XKB. The error message is:
>
>Test   7:  FAIL
>  XStringToKeysym() returned NoSymbol for string "Greek_IOTAdiaeresis".
>
>>What are the reported problems for the other three (XListPixmapFormats,
>>XAllocNamedColor, XLookupColor)?
>
>Tests for XListPixmapFormats
>Test   1:  FAIL
>  XListPixmapFormats() returned 7 structures
>  Expected 6 structures

I believe that this was fixed for the 4.4.99.22 snapshot.  The problem here
was in libX11.  Are you running xtest against a recent libX11?

>Summary of Results for XListPixmapFormats
>-----------------------------------------
>PASS         0
>FAIL         1
>UNTESTED     1
>
>
>
>Tests for XAllocNamedColor
>Test   2:  FAIL
>  --- Running test with visual class PseudoColor, depth 8
>  --- Testing with supported visual class PseudoColor
>  --- Running test with visual class GrayScale, depth 8
>  --- Testing with supported visual class GrayScale
>  Colour names "gray" and "sky blue" yield the same supported rgb values.
>  Colour names "dim gray" and "magenta" yield the same supported rgb 

It looks to me like these tests are not taking into account the
rounding that happens with coarse GrayScale and and TrueColor
visuals.  The tests themselves probably need to be reworked.

David
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.