SiS 630 - framebuffer fixed

SiS 630 - framebuffer fixed

[Thomas Winischhofer]

Hi,

after five days of struggle with reverse-engineered assembler code
transformed to C, I could fix the SiS framebuffer driver for use with
some LCD displays using a LVDS (Chromtel) video bridge. That is what
most laptops use, as for example the Gericoms (and some Claveos I have
heard).

Since I had to re-write a large part of the (totally uncommented) code,
I have not yet made a patch (which would be _huge_). Instead, you can
find the complete source on 

   http://members.aon.at/~twinisch/sisfb.tar.gz

for download. Just cd to /usr/src/linux/drivers/video/sis/ and extract
the archive there. I based the code on the one contained in kernel
2.4.16 (I saw no sisfb updated in 2.4.17-preX/rcX so this should do.)

To select a mode, either

a) append a kernel parameter, eg. video=sisfb:mode:1024x768x16

or

b) insmod it with the command line "insmod sisfb mode=1024x768x16"

Default mode is 800x600x8 which has problems on LCD panels (see below).

Caveats and issues:

1) I had to change the driver in its very basics for make it work on
LVDS/Chromtel bridges. LVDS data tables were empty in the driver, so
this couldn't have worked by any means. I re-wrote large parts of the
code (hopefully not touching anything not-LVDS-related) to make the
driver read the data contained in the BIOS. This implys the following
issue:

The driver relies - if an LVDS bridge (with or without Chromtel/Trumpion
TV converter) is to be used - on a machine with a BIOS. It will _not_
work with LinuxBIOS. As I believe that LinuxBIOS is not widely used
anyway, I think we could live with that.

2) The driver currently only displays 16bpp modes correctly on LCD
screens (using LVDS bridges, that is). I am working on this and will
release a patch as soon as I found the problem. (VGA is OK). Currently,
the image is very dark on the LCD and - as it seems - in black & white
(???).

3) The current X driver from CVS does work in combination with the
framebuffer driver, but there seems to be at least one problem (not
leading into further trouble on my machine, yet) with the hardware
cursor. I don't know whether this is memory management related or not,
however, to fix this is beyond my scape of knowledge.

4) DRM works fine, as long as you set the memory to more than 16MB.
Below that I saw occasional screen corruption (which again makes me
believe that it's a memory management problem).

5) TV-out doesn't work. The tables in the driver are empty and I have no
idea where to find the data in the BIOS.

6) If you intend to use DRM under X, a word on this: It works. BUT:

 a) If the sisfb is compiled as a module and not insmod'ed _before_ the
X driver takes over (so to say), it for some reasons is not able to
detect the video bridge type. This is possibly a hardware problem; it
seems the X driver did something odd that leads into wrong data in the
SiS hardware registers. 

 b) If the sisfb is compiled into the kernel or insmod'ed _before_ X
starts, this problem does not occure.

 c) Always set the video memory to the maximum available. Low mem
situations are not handled well by DRM/DRI.

Now my list of "pleases":

A) Please test the driver and report the result to me. Always include
the corresponding part of the syslog and describe exactly what modes
with what depth you used and what you saw on the screen. Report's like
"I used your driver and I saw nothing" are completely useless.

B) Please report also _when_it_works_. I have no idea how many of you
actually use a SiS chipset so that's interesting to know either.

C) A final please: People _not_ using an LVDS bridge should also test
the code. As said, I tried not to touch anything not-LVDS-related, but
.. ya' never know...

Thomas

PS: Marcello/Linus: If you insist, I would make a patch as well.

PPS: After those five days I need to do something else. Like play Qu*ake
III ... on my SiS 630 :)

-- 
Thomas Winischhofer
Vienna/Austria
mailto:tw@webit.com              *** http://www.webit.com/tw

Re: SiS 630 - framebuffer fixed

[David Mansfield]

On Wed, 19 Dec 2001, Thomas Winischhofer wrote:

> 
> Hi,
> 
> after five days of struggle with reverse-engineered assembler code
> transformed to C, I could fix the SiS framebuffer driver for use with
> some LCD displays using a LVDS (Chromtel) video bridge. That is what
> most laptops use, as for example the Gericoms (and some Claveos I have
> heard).
> 
...
>  c) Always set the video memory to the maximum available. Low mem
> situations are not handled well by DRM/DRI.

I've actually been following your progress via the Xpert list archives.  
Good stuff.  I have an SiS 630 card not in a laptop, and I'll try your 
code out later.  But my question regards DRM and something mentioned on 
that list, TurboQueue...

When I use the DRM code with XFree 4.1 it usually freezes after about 30 
seconds or so (in the teapot demo - sooner with tuxracer) and I think I've 
tracked it down to the 'mWait3DCmdQueue' macro, which basically busy waits 
for a certain register value.  It just so happens that the TurboQueue code 
also happens to busy wait on this register, and it was causing hangs for 
you with just 2d code (right?).

Do you know anything about why these hangs were happening?

I'll try your code tonight (although sisfb has always worked for me!) and 
hopefully the CVS X code with DRM.  I'll let you know if it still works, 
and send you my X startup log.


David


-- 
/==============================\
| David Mansfield              |
| david@cobite.com             |
\==============================/

Re: SiS 630 - framebuffer fixed

[Thomas Winischhofer]

Hi again.

After a few feedbacks on the framebuffer driver, I will do the
following:

1) For testing reasons, I will include my BIOS in the driver code. 

The reason for this is that I saw that the machines in question partly
have old video BIOSes (mine has a 2.xx.x while I saw one guy with
1.06.x; that old BIOS isn't even detected as a VESA BIOS).

By this measure, I will be able to estimate whether or not the whole
matter is actually BIOS related or not. If it is, you all may get
lucky...!

I am aware that this is no permanent solution for copyright reasons, but
for testing it will do.

2) Further, I will include code to write the video BIOS of a machine to
disk. All people testing this are being asked to send that file to me
then. 

Unfortunately, I have to work today, so don't count on a new version
today.

Thomas

PS: To all people testing the driver (or the X driver): Please send me
the logs! Some of you actually forgot to do that....

-- 
Thomas Winischhofer
Vienna/Austria                  Check it out:
mailto:tw@webit.com              http://www.webit.com/tw