XGI Volari not supported by Ubuntu

[Starmaker]

Appearently my XGI Volari V3 video card will not work with releases later than 6.06 LTS. Did something change with the drivers available in the xserver? The Trident driver works marginally and thinks that I have a different Volari Card. The old Mesa driver in Dapper works wonderfully for everything except some games with intense graffix.

Why is this? Is there something I can do other than convert to Edgy to run on Xfree86 until the next time I install an upgrade? (I already tried this method once, and may try it again later.)
[lspci]
0000:00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1)
            Subsystem: ASUSTeK Computer Inc.: Unknown device 80ac
0000:02:00.0 VGA compatible controller: Trident Microsystems XGI Volari XP5 (rev 02) (prog-if 00 [VGA])
            Subsystem: Trident Microsystems XGI Volari XP5

[Alan Coopersmith (alan-coopersmith)]

*** Bug 5776 has been marked as a duplicate of this bug. ***

[Alan Coopersmith (alan-coopersmith)]

*** This bug has been marked as a duplicate of 4285 ***

[Kwolfli (kwolfli)]

This is not a duplicate of 4285. The XP5 chipset in the ECS 532 is detected
correctly now that 4285 is fixed, still it doesn't work. The screen just is
turning from black to white slowly, beginning at the top and the bottom,
towards the middle of the screen. After a couple of seconds it then turns back
again to black.

[Davpal (davpal)]

Driver works using the external VGA port but not de Panel.
In logs driver detect an 1280x1024 TFT Panel and ecs 532 use a 1024x768 Panel,
can be that the problem?
Thanks

[Davpal (davpal)]

Changing to the LCD mode 1280x1024 in trident_driver.c by 1024x768 the X start
and few seconds are seen correctly but finally it returns to happen the same.
Nevertheless now if that is possible to close the X with Ctrl+Shift+Del.

[Xorg-gkdq (xorg-gkdq)]

Created an attachment (id=7684)
Workaround against wrongly detected panel size on Volari XP5

David, in #5 you don't tell what you've actually tried. Please test the patch
attached to this comment, it works for me.

Make also sure you're using trident version 1.2.3, or at least: remove the
single line in src/xp4_accel.c:248. Without there were some funny effects.

[Davpal (davpal)]

The patch works fine and now the X are pretty in ecs 532.
Thanx

[Alanh-fairlite (alanh-fairlite)]

Thanks for testing. Closing.

[Simon-triebenbacher (simon-triebenbacher)]

*** Bug 9426 has been marked as a duplicate of this bug. ***

[Starmaker (starmaker)]

Appearently my XGI Volari V3 video card will not work with releases later than 6.06 LTS. Did something change with the drivers available in the xserver? The Trident driver works marginally and thinks that I have a different Volari Card. The old Mesa driver in Dapper works wonderfully for everything except some games with intense graffix.

Why is this? Is there something I can do other than convert to Edgy to run on Xfree86 until the next time I install an upgrade? (I already tried this method once, and may try it again later.)

[Brian Murray (brian-murray)]

Thanks for your bug report. Could you please add the full output of 'lspci -vv' and 'lspci -vvn' as attachments? Thanks in advance.

[Starmaker (starmaker)]

I hope that this helps you because it would be really nice to be able to update to the newer releases. They worked a lot faster when I could get them running. They are also quite attractive with wonderful artwork and really nice themes. Good work ppl!

[Brian Murray (brian-murray)]

Is the mesa driver the one you use in Dapper?

[Starmaker (starmaker)]

I don't know how to tell again, but I tried to install and play doomIII for linux and the reason I couldn't was because the Mesa driver couldn't handle it.

When I run the command #sudo dpkg-reconfigure xserver-xorg It doesn't have any mesa driver available, and shows vesa instead.

I will try to go back and look for the command used to determine the driver I'm using, but Whatever it is, Dapper selected it automatically upon install. I have not been able to get an Edgy CD to work properly, but I also have not been able to get a freely shipped cd. I have been upgrading using #gksu "update-manager -c" and the update manager. But I won't do that again because of the "301 moved permanently" problem with the repositories.

I will attemp to find all of the information I should have had to begin with when going to report this bug. I still don't know what all you might need though. I think that it is great how well my bug reports have been recieved!

Thanks for the cooperation!

> -----Original Message-----
> From: <email address hidden>
> Sent: Wed, 21 Feb 2007 16:53:39 -0000
> To: <email address hidden>
> Subject: [Bug 86550] Re: Video card no longer supported by Ubuntu
>
> Is the mesa driver the one you use in Dapper?
>
> --
> Video card no longer supported by Ubuntu
> https://launchpad.net/bugs/86550

[Starmaker (starmaker)]

okay This is my glxinfo, and /etc/X11/xorg.conf readouts.

[Starmaker (starmaker)]

those two files are from 6.06. I can update to the 6.10, but it is difficult and time consuming. I don't think that there would be any use becaue the glxinfo and lspci wouldn't be the same because I have to use drivers that weren't meant for the video card anyway.

Tell me what you need to know and I will try to supply it. I am learning a lot about the xserver and xfree86 and may be able to come up with some kind of fix on my own. If I do I will let you know.

[Timo Aaltonen (tjaalton)]

it seems that you are using vesa-driver on dapper.. doesn't that work in edgy? You could try feisty, herd-4 test-release was released last week.

[Starmaker (starmaker)]

no, the vesa driver doesn't work in edgy for some reason. It doesn't do anything after the splash screen and using pdkg-reconfigure xserver-xorg doesn't even work if I try using the vesa driver.

Thanks anyway.

> -----Original Message-----
> From: <email address hidden>
> Sent: Fri, 23 Feb 2007 07:53:39 -0000
> To: <email address hidden>
> Subject: [Bug 86550] Re: Video card no longer supported by Ubuntu
>
> it seems that you are using vesa-driver on dapper.. doesn't that work in
> edgy? You could try feisty, herd-4 test-release was released last week.
>
> --
> Video card no longer supported by Ubuntu
> https://launchpad.net/bugs/86550

[Timo Aaltonen (tjaalton)]

Reassigning to discover. It's this device (/lib/discover/pci.lst):

        10232200 unknown unknown XGI Volari XP5

and it needs to be modified to use trident driver.

[Starmaker (starmaker)]

The problem is that there is no trident driver for my XGI Volari V3 video card for use with Xorg. There is one from the XGI site that is an .RPM which I converted into a .deb but then didn't know how to try and implement it. The .rpm version of the driver is located Here: http://www.xgitech.com/sd/sd_download2.asp

XGI says that it only supports Xfree86, so I converted Edgy to run on Xfree86 instead of xorg, but that didn't go so well because I still didn't know how to use the downloaded and converted driver after i installed it. If there were a "how to" that explained step by step how to do this successfully it would be nice. Is there a way to use xfree86 and Xorg simultaneously perhaps with xfree86 master and xorg slave? I haven't found enough information on the subject. If there is a way and I had access to the info I could write a patch script and upload it.

Thanks again for the support I greatly appreciate it.

P.S. the trident Volari XP5 driver works in Edgy, except that I cannot move anything on the desktop or scroll upwards without problems. Scrolling down works fine. Though I don't think it should work at all. I don't know enough, and can't find info.

[Timo Aaltonen (tjaalton)]

Ah, ok.. so trident driver needs support for this device.

That leaves the vesa-driver problem. You didn't say how it doesn't work.. Try with Feisty Herd5, and run 'sudo xresprobe vesa' in the terminal and post the results. Also, attach /var/log/casper.log, Xorg.0.log and the resulting xorg.conf.

[Timo Aaltonen (tjaalton)]

actually, there is a new driver in Xorg git, called xgi. It has not seen any releases so far, so I think it has been herited from XGI. Unfortunately, I don't think we'll see a release before feisty, so you'll have to live with vesa for a while.

[cropr (ruben-decrop)]

I also have an Xgi Volari CP5 card

When booting Edgy or Feisty Herd 5, I get a black screen when X starts and the system hangs.

Installing Dapper works fine (it uses the vesa driver). After upgrading Dapper to Edgy the system does not want to start X. The xorg.conf was not changed, so the vesa driver does not work anymore with XGI Volari card. I tried to change to trident driver: X does start but this driver is clearly buggy or this card

[Starmaker (starmaker)]

I finally got the feisty Herd 5 alternate install CD, made certain that it was burned correctly and have the exact same result cropr has with his Volari CP5.

[grkravi (grkravi)]

Well. i have a Dell inspiron 5160 laptop with XGI Volari XP5 video card. I was using vesa with dapper.
With edgy though, i have been using the trident driver with xorg and it is working very well at 1440*1050.
There is a bug report #67620 already in launchpad and also the trident driver. The steps for installing is also given.
Here is the link...please see if this works with feisty.
https://launchpad.net/ubuntu/+source/xserver-xorg-video-trident/+bug/67620

[Brice Goglin (brice-goglin)]

As explained By Christoph in http://lists.freedesktop.org/archives/xorg/2007-May/024341.html
we don't see how this bug got resolved. Christoph's patch didn't get applied, and I don't see any other commit related to this XP5 problem.
I am reopening.

[Alanh-fairlite (alanh-fairlite)]

Created an attachment (id=11432)
Try to fix maximal resolution supported by LCD

Does this patch work instead ?

[Alanh-fairlite (alanh-fairlite)]

Oh, and can someone upload a full log with the actual problem and no patches applied ??

[Davpal (davpal)]

(In reply to comment #12)
> Oh, and can someone upload a full log with the actual problem and no patches
> applied ??
>

Helo,
The problem persist witch the last patch.
The log without patch are the following:

(II) LoadModule: "trident"
(II) Loading /usr/lib/xorg/modules/drivers//trident_drv.so
(II) Module trident: vendor="X.Org Foundation"
(II) TRIDENT: driver for Trident chipsets: tvga9000, tvga9000i, tvga8900c,
(**) TRIDENT(0): Depth 24, (--) framebuffer bpp 32
(II) TRIDENT(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
(==) TRIDENT(0): RGB weight 888
(==) TRIDENT(0): Default visual is TrueColor
(**) TRIDENT(0): Using gamma correction (1.0, 1.0, 1.0)
(==) TRIDENT(0): Using XAA for acceleration
(==) TRIDENT(0): Linear framebuffer at 0xF0000000
(--) TRIDENT(0): IO registers at 0xFE400000
(II) TRIDENT(0): initializing int10
(II) TRIDENT(0): Primary V_BIOS segment is: 0xc000
(II) TRIDENT(0): VESA BIOS detected
(II) TRIDENT(0): VESA VBE Version 2.0
(II) TRIDENT(0): VESA VBE Total Mem: 32768 kB
(II) TRIDENT(0): VESA VBE OEM: XGI Volari XP5
(II) TRIDENT(0): VESA VBE OEM Software Rev: 2.0
(II) TRIDENT(0): VESA VBE OEM Vendor: XGI TECHNOLOGY INC.
(II) TRIDENT(0): VESA VBE OEM Product: Volari XP5
(II) TRIDENT(0): VESA VBE OEM Product Rev: AXEC 7.4 (42.08)02
(II) TRIDENT(0): VESA VBE DDC read failed
(--) TRIDENT(0): Revision is 2
(--) TRIDENT(0): Found XP5 chip
(--) TRIDENT(0): RAM type is SGRAM
(--) TRIDENT(0): Using HW cursor
(--) TRIDENT(0): VideoRAM: 65536 kByte
(--) TRIDENT(0): TFT Panel 1280x1024 found
(--) TRIDENT(0): Memory Clock is 66.00 MHz
(==) TRIDENT(0): Min pixel clock is 12 MHz
(--) TRIDENT(0): Max pixel clock is 115 MHz
(II) TRIDENT(0): Monitor genérico: Using hsync range of 31.50-48.00 kHz
(II) TRIDENT(0): Monitor genérico: Using vrefresh range of 56.00-65.00 Hz
(II) TRIDENT(0): Clock range: 12.00 to 115.00 MHz
(II) TRIDENT(0): Not using default mode "640x350" (vrefresh out of range)
(II) TRIDENT(0): Not using default mode "320x175" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "640x400" (vrefresh out of range)
(II) TRIDENT(0): Not using default mode "320x200" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "720x400" (vrefresh out of range)
(II) TRIDENT(0): Not using default mode "360x200" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "320x240" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "640x480" (vrefresh out of range)
(II) TRIDENT(0): Not using default mode "320x240" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "640x480" (vrefresh out of range)
(II) TRIDENT(0): Not using default mode "320x240" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "640x480" (vrefresh out of range)
(II) TRIDENT(0): Not using default mode "320x240" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "400x300" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "400x300" (bad mode clock/interlace/doublescan)
(II) TRIDENT(0): Not using default mode "800x600" (vrefresh out of range)
(II) TRIDENT(0...

[Alanh-fairlite (alanh-fairlite)]

Can you remove your hsync/vrefresh settings in your config file and re-upload a log again without the patch ?

[Davpal (davpal)]

Created an attachment (id=13660)
Xorg log without any patch and Refresh settings

[Alanh-fairlite (alanh-fairlite)]

Are you sure that's without any hsync/vrefresh settings as I still see this in the log.....

(II) TRIDENT(0): Monitor gen�rico: Using default hsync range of 31.50-37.90 kHz
(II) TRIDENT(0): Monitor gen�rico: Using default vrefresh range of 50.00-70.00 Hz

Which sounds to me like you are specifying a range ?

If so, try without them and upload a new log or post your xorg.conf too.

[David (dvdkhlng)]

I have the same problem with the Volari XP5 on an ECS-532 notebook. For now I fixed it by hardcoding a single line:

    pTrident->displaySize = 1024;

into the TRIDENTPreInit() routine. I also have to add hsync/vrefresh lines to my monitor section in order for the driver to actually use the 1024x768 resolution. Else it sets 800x600 and I only see a blank screen.

Snipset from my xorg.conf:

Section "Device"
        Identifier "Configured Video Device"
        Driver "trident"
        Option "Display" "LCD,CRT"
EndSection

Section "Monitor"
        Identifier "Configured Monitor"
        HorizSync 28-51
        VertRefresh 43-60
EndSection

This is with Ubuntu 8.04 (xorg 1:7.3+10ubuntu10.2), trident driver 1:1.2.4-1. For reference, please see also my private SVN repository of the patched ubuntu driver source:

http://mosquito.dyndns.tv/freesvn/xorg-trident-ecs532

So what about finally comitting Christoph's patch, which seems to do the right thing? And what would be the right solution about those required monitor timings?

I'm also currently tinkering with making XV work for the XP5 chipset with some success so far and am going to post a patch soon.

I'll be happy to supply any additional information you need.

cheers,

David

[David (dvdkhlng)]

Created an attachment (id=20574)
Patch required for XV to work on XP5 chipset

The unpatched driver only displays a black window when attempting to display video via XV. Looks like XP5 chipset was just omitted in a few 'if'-statements in the sources.

This patch was tested on a ECS-532 laptop, lspci -v output:

01:00.0 0300: 1023:2200 (rev 02) (prog-if 00 [VGA controller])
        Subsystem: 1019:0f56
        Flags: bus master, 66MHz, medium devsel, latency 8, IRQ 11
        Memory at f0000000 (32-bit, non-prefetchable) [size=128M]
        Memory at fe400000 (32-bit, non-prefetchable) [size=4M]
        Memory at e8000000 (32-bit, non-prefetchable) [size=128M]
        Memory at fe9f8000 (32-bit, non-prefetchable) [size=32K]
        Expansion ROM at fe980000 [disabled] [size=256K]
        Capabilities: <access denied>

I patched the xorg driver source package that came with Ubuntu 8.04. For reference, the full patched source I used is available via SVN here:

http://mosquito.dyndns.tv/freesvn/xorg-trident-ecs532

This currently only works with 24 bit depth, tested with mplayer and totem. On 16 and 15 bit depth, mplayer repeatedly issues the following error:

  X11 error: BadAlloc (insufficient resources for operation)

and displays an image of constant color. Totem just exits when trying to play a movie on 15 or 16 bit.

Also see the C comments in the patch.

[N64 (n64)]

Here is patched source code of xorg-video-trident-1.2.4-1
http://mosquito.dyndns.tv/freesvn/trunk/xorg-trident-ecs532/

And here is patched source code of xf86-video-trident-1.3.1
http://free.of.pl/d/dcast/xf86-video-trident-ecs-532-patched-1.3.1.tar.bz2

And here is my xorg.conf
http://free.of.pl/d/dcast/xorg.conf

This "wrong size panel" patch doesn't solve all the problems, becouse the problem probably is in Xorg, not in trident driver. When I run Xorg with vesa driver, there's still the same, wrong panel size bug. Again, there should be 1024x768, but there is 1400x1200.

When I run Xorg 6.9 in Slax 5.1.8, vesa mode works very well in 1024x768. But in newest Xorg, it crash or display 1400x1200 (depends on what is in my xorg.conf).

=== this is how looks my xorg.conf in vesa mode that display 1400x1200===

Section "Monitor"
Identifier "LCD"
VendorName "Monitor Vendor"
ModelName "Monitor Model"
HorizSync 31.5 - 64.3
VertRefresh 50-70
EndSection

Section "Device"
Identifier "Card0"
Driver "vesa"
EndSection

Section "Screen"
 Identifier "Screen0"
 Device "Card0"
 Monitor "LCD"
...........................

[Tony Travis (ajtravis)]

This is an old bug, but is still present in Lucid (10.04 LTS), Maverick (10.10) and Oneric (11.10)

  Tony.