after upgrade to 8.10 (new x.org) SiS driver is not working well (issue with color depth?)

[Jiří Navrátil]

Binary package hint: xserver-xorg-video-sis

after upgrade to 8.10, I do not see correctly colors, it's very bad for eys (all colors are changing in cyrcle, setting one color background little help to use terminal), it's like wrong color depth, only solution is set vesa as driver

        Identifier "Card0"
        Driver "sis"
        VendorName "Silicon Integrated Systems [SiS]"
        BoardName "661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter"
        BusID "PCI:1:0:0"

X.Org X Server 1.5.2
Release Date: 10 October 2008
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-19-server i686 Ubuntu
Current Operating System: Linux bilbo 2.6.27-3-rt #1 PREEMPT RT Mon Oct 27 03:05:19 UTC 2008 i686
Build Date: 24 October 2008 08:00:16AM
xorg-server 2:1.5.2-2ubuntu3 (<email address hidden>)
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Module Loader present
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Thu Oct 30 23:11:55 2008
List of video drivers:
 s3
 sis
 radeon
 tdfx
 glint
 voodoo
 v4l
 i810
 tseng
 r128
 siliconmotion
 tga
 mach64
 chips
 sisusb
 cirrus
 rendition
 ztv
 mga
 nv
 savage
 s3virge
 i740
 intel
 dummy
 openchrome
 geode
 trident
 vmware
 i128
 ati
 vga
 ark
 nsc
 apm
 neomagic
 fbdev
 vesa
Xorg: symbol lookup error: /usr/lib/xorg/modules/drivers//vga_drv.so: undefined symbol: xf86GetPciVideoInfo

[Tore Anderson (toreanderson)]

I can confirm this bug.

I upgraded an Asus A6000 laptop from Hardy to Intrepid, and while Hardy worked fine, the colours was horribly messed up in X after the upgrade. I'll be attaching a screenshot as well as a literal screenshot (taken with a camera), so you can compare. It would be good if you could confirm if this indeed is the same bug and that the corruption you're seeing is similar to mine, Jiří.

Info about the graphics card from lspci -vv:

01:00.0 VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760PCI/AGP or 662/761Gx PCIE VGA Display Adapter
        Subsystem: ASUSTeK Computer Inc. Device 1102
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
        Interrupt: pin A routed to IRQ 10
        BIST result: 00
        Region 0: Memory at d0000000 (32-bit, prefetchable) [size=128M]
        Region 1: Memory at deee0000 (32-bit, non-prefetchable) [size=128K]
        Region 2: I/O ports at ac00 [size=128]
        Capabilities: <access denied>
        Kernel modules: sisfb

I'll be also attaching output from Xorg.0.log as well as /etc/X11/xorg.conf (which hasn't been touched in several months, the upgrade left it intact).

Tore

[Tore Anderson (toreanderson)]

Eh, in case it wasn't obvious, I swapped the image files, so the following link to the screenshot with the cam will actually show the screenshot taken with scrot and vice verca.

Apologies for the confusion.

Tore

[Tore Anderson (toreanderson)]

By the way, while the vesa driver produce correct colours, it's not a fully satisfactory workaround, as X ends up using a resolution of 800x600 which looks really horrible. The native resolution of the display is 1280x800, which the sis driver is using correctly.

So with Intrepid I need to choose between a broken resolution or broken colours. Both options anger my girlfriend -- the owner of the laptop in question -- so this bug is (for me) absolutely critical..! Please help! :-P

Tore

[Tore Anderson (toreanderson)]

I've found a workaround that makes the sis driver display colours correctly, in the right resolution. When I make sure the sisfb kernel module is loaded prior to X being started (for instance by adding it to /etc/modules), everything seems to work like it did in Hardy - completely fine, that is. The sisfb module isn't loaded automatically (I don't know if it was in Hardy or if it was simply not necessary for it to be loaded for the sis driver to work correctly).

So I won't have to sleep on the couch tonight after all... :-)

Tore

[Jiří Navrátil (plavcik)]

Thx Tore for adding your comments , inputs and sisfb info.

I can confirm, that http://launchpadlibrarian.net/19192377/img_3907.jpg is showing same problem I have.

I also tested boot from installation CD. The result is the same => is not related to upgrade only but to new x.org

I'm trying to get sisfb workarround working as suggested by Tore. sisfb is in /etc/modules
 So far, I'm unfortunatelly getting
- without xorg.conf
(WW) SIS: More than one matching Device section found: Builtin Default sis Device 0
(EE) open /dev/fb0: No such file or directory

- with xorg.conf and Driver sis, the situation is still bad, I have to found, how to force sisfb driver in xorg.conf (or something to be added to /etc/modules or grub menu.lst?)

In BIOS, I have
Boot Display Device LCD
Share Memory 128MB

[Jiří Navrátil (plavcik)]

I tested, if sisfb is loaded. I had noticed, that amd64_agp is loaded too. Is that correct for AMD Mobile Sempron 3300+ ? I think, this is not 64bit CPU. I'm using 32bit distribution.

lsmod | grep sis
sisfb 243796 0
sis_agp 7168 0
agpgart 33484 2 sis_agp,amd64_agp
pata_sis 10244 10
libata 167776 3 pata_sis,pata_acpi,ata_generic

[Tore Anderson (toreanderson)]

I think the Sempron is a 64-bit capable processor, so it makes sense that a amd64-* module is loaded even though you're using a 32-bit operating system. Anyway:

(EE) open /dev/fb0: No such file or directory

is telling, for some reason /dev/fb0 didn't show up when you loaded the sisfb kernel module. Either your particular chipset isn't supported by the sisfb driver and you're out of luck, or something else is amiss...

When I load the sisfb driver, I see the following appear in the dmesg output:

sisfb: Video ROM found
sisfb: Video RAM at 0xd0000000, mapped to 0xded00000, size 32768k
sisfb: MMIO at 0xdeee0000, mapped to 0xdec80000, size 128k
sisfb: Memory heap starting at 32160K, size 32K
sisfb: Detected SiS302LV video bridge
sisfb: Detected 1280x800 flat panel
sisfb: Detected LCD PDC1 0x00 (for LCD=CRT1)
sisfb: Default mode is 1280x800x8 (60Hz)
sisfb: Initial vbflags 0x8000012
Console: switching to colour frame buffer device 160x50
sisfb: 2D acceleration is enabled, y-panning enabled (auto-max)
fb0: SiS 760 frame buffer device version 1.8.9
sisfb: Copyright (C) 2001-2005 Thomas Winischhofer

This looks normal - as you can see it detects the LCD's native resolution of 1280x800, and it's assigned the name "fb0", and afterwards /dev/fb0 shows up as a character device with major number 29, minor number 0. Presumably udev is responsible for that. The text-only console has also changed resolution, so the text is smaller and crisper. You should look into why /dev/fb0 doesn't appear, if it is because of a failure in sisfb (should be apparant in dmesg if so), or if it is because udev doesn't correctly create /dev/fb0. If it's the first case you might be able to try a few module options (see "modinfo -p sisfb" for a list of available ones) and hopefully make it work, if it's the last case you can possibly work around it by doing "mknod /dev/fb0 c 29 0", perhaps also making sure the "video" group can write to the created device node.

You should probably also make sure that you're running the latest available kernel (2.6.27-7-generic here).

Good luck!

Tore

[Jiří Navrátil (plavcik)]

Thx Tore, it helped me to find, how to enable sisfb workarround for me too.

I had to change in BIOS Share Memory from 128MB to 64MB. Now it's working for me too (full resolution, colors fine)

[Tore Anderson (toreanderson)]

Great, glad I could help. :-)

Tore

[Jerome Bourget (jeromebourget-deactivatedaccount)]

I experimented the same problem,

The workaround worked well for me too,

Thanks !

Jérôme

[Pierre Equoy (pieq)]

Hey there,

I just installed Intrepid Ibex and got the same issue as you guys, since I also have an Asus A6U laptop with this crappy SiS graphic card...

First of all: thank you all! The workaround described seems to work fine (as long as I don't share more than 64MB of memory in the BIOS)

But unfortunately I'm now experiencing a very annoying problem when the graphic context "changes too much" -- resizing a window in Gnome, watching a video, etc.: many white or green horizontal lines appear for a very brief period then disappear... it's really annoying, especially since this did not happen under Hardy (or only when I was playing some DVDs).

Do you experience the same problem? Have you found a way to get through it?

Thanks in advance!

[Tore Anderson (toreanderson)]

No such problems here, ePierre. Sorry.

Maybe it could be caused by compiz (desktop effects) though - I think I've heard this is enabled by default in Intrepid. My girlfriend is only using plain Openbox with no compositing eye-canding. It's a long shot but you could try turninig it off (don't know how/where though).

Tore

[Jiří Navrátil (plavcik)]

ePierre . I'm experiencing the same issue. It happen sometimes and only when playing full screen video in mplayer.

(no compiz/desktop effects)

Jiri

[Le Monolecte (monolecte)]

Hello everybody from France!
Same chipset, same punishment : I have dirty colors on my screen since I was upgraded to Ibex.
It the big bad surprise of the mouth, and I'm working as... graphist (too bad for me!)

lsmod | grep sis
sis_agp 15232 0
i2c_sis96x 12420 0
agpgart 42184 2 sis_agp,amd64_agp
i2c_core 31892 1 i2c_sis96x
pata_sis 18436 3
libata 177312 3 ata_generic,pata_sis,pata_acpi
sis900 27904 0
mii 13440 1 sis900

I read this thread, but I don't understand hox you make to soluce this (How can we change the share memory in the BIOS?)

So, it's a vera critical bug for me and sis corporation's products are blacklited for ever fot me!

(the hungry frog! :-) )

[Le Monolecte (monolecte)]

Hello everybody from France!
Same chipset, same punishment : I have dirty colors on my screen since I was upgraded to Ibex.
It the big bad surprise of the mouth, and I'm working as... graphist (too bad for me!)

lsmod | grep sis
sis_agp 15232 0
i2c_sis96x 12420 0
agpgart 42184 2 sis_agp,amd64_agp
i2c_core 31892 1 i2c_sis96x
pata_sis 18436 3
libata 177312 3 ata_generic,pata_sis,pata_acpi
sis900 27904 0
mii 13440 1 sis900

I read this thread, but I don't understand how you make to soluce this (How can we change the share memory in the BIOS?)

So, it's a vera critical bug for me and sis corporation's products are blacklited for ever fot me!

(the hungry frog! :-) )

[Le Monolecte (monolecte)]

Too bad : I had already 64MB in my BIOS...

[Le Monolecte (monolecte)]

I have a working solution for SiS 760 in Acer Aspire 5000.
- Keep the xorg.conf generated by the upgrade to Ibex
- Add this line in the /etc/modules file :
sisfb

Reboot and enjoy an another life in true colors :-)

[Tostao (tostao)]

woooooow thanks it's working I was becoming mad!!
Thanks a lot!!

[Szabolcs Parragh (parszab)]

I would like to confirm this very serious bug. I experience this on my Asus L4000. The workarounds didn't work for me on this laptop!

[Igor Starikov (idlesign)]

The same for 9.04.
sisfb in /etc/modules in a way fixes the problem (still have randomly apearing white lines when in fullscreen video).

[komputes (komputes)]

I can confirm the issues of color depth, static, and white lines on both the LCD and external monitor.

Hardware: VGA compatible controller: Silicon Integrated Systems [SiS] 661/741/760 PCI/AGP or 662/761Gx PCIE VGA Display Adapter

[kendatsuba (kendatsuba)]

Hi everybody.
Same problem here (see attached image): Asus laptop model L400L, VGA compatible controller: SiS 65x/M650/740.
Unfortunately the proposed fix (adding sisfb to /etc/modules) doesn't help. However I think I found a working fix for my hardware so please read on.
Comparing Xorg logs generated by Hardy (not affected by this bug) and the ones from Jaunty (see attachments) I found this important difference in the output:

Hardy:

(--) SIS(0): Video BIOS version "1.15.01" found (old SiS data layout)

Jaunty (this line is also present in every log you posted):

(WW) SIS(0): Could not find/read video BIOS

Inspecting the driver source I discovered that in the transition from version 0.9.3 to 0.10.1 a substantial amount of code gets bypassed if Xorg 7.4 is detected. This is so because that piece of code is not compatible with Xorg 7.4 pci rework (http://www.x.org/wiki/PciReworkHowto). Let's get straight to point: that bypassed code is (guess what) part of the bios detection routine: it is the last attempt made by the driver to load the card bios and gets called if all previous "standard" attempts have failed. That was the problem.

The solution: instead of rewriting the bypassed code I just forced the driver to read the card bios using one of the aforementioned "standard" attempts. Luck was on my side, It worked!

You will find the logs, the patch and the patched i386 deb in a tar.gz attached to this message. The fix should work with SIS_650 (tested - see attached image) and SIS_660 (not tested). Could you please test it?

Best regards,
Matteo

[Marcos Sánchez Provencio (rapto)]

I can confirm the bug is still present in karmic. My friend's old laptop screen looks like the one attached in #25

I made it work for a while starting X in vesa driver, then in sis driver with Options vesa True.

I am going to try to install the .deb attached or reapply the patch and recompile (it will remind me of the times recompiling the kernel to make the sound card work :-)

[kendatsuba (kendatsuba)]

Dear Marcos,
please refer to bug #264769:

https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-sis/+bug/264769?comments=all

There you will find an up-to-date version of this patch and a patched deb package for Karmic. Thanks to Tormod Volden you can also find a patched deb in the following PPAs:

https://launchpad.net/~tormodvolden/+archive/ppa
https://launchpad.net/~xorg-edgers/+archive/drivers-only

Hope this helps.
Best regards,
Matteo