can anybody answer is this cards will be supported ? XGI volari XP5 and V3 support (trident based) on my notebook ecs532 installed xp5 and it working not bad in windows in 32 bit mode in linux speed of drawing is droping while using fbdev driver and vesafb in 16 bit mode but hoping for the best ?
*** Bug 5776 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 4285 ***
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.
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
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.
Created attachment 7684 [details] [review] 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.
The patch works fine and now the X are pretty in ecs 532. Thanx
Thanks for testing. Closing.
*** Bug 9426 has been marked as a duplicate of this bug. ***
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.
Created attachment 11432 [details] [review] Try to fix maximal resolution supported by LCD Does this patch work instead ?
Oh, and can someone upload a full log with the actual problem and no patches applied ??
(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): 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): Not using default mode "400x300" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "800x600" (hsync out of range) (II) TRIDENT(0): Not using default mode "400x300" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1024x768" (vrefresh out of range) (II) TRIDENT(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1024x768" (hsync out of range) (II) TRIDENT(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1024x768" (hsync out of range) (II) TRIDENT(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1024x768" (hsync out of range) (II) TRIDENT(0): Not using default mode "512x384" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1152x864" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "576x432" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1280x960" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1280x960" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "640x480" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1280x1024" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "640x512" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1280x1024" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "640x512" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1280x1024" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "640x512" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1600x1200" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1600x1200" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1600x1200" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1600x1200" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1600x1200" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "800x600" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1792x1344" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "896x672" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1792x1344" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "896x672" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1856x1392" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "928x696" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1856x1392" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "928x696" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1920x1440" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "960x720" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1920x1440" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "960x720" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "832x624" (hsync out of range) (II) TRIDENT(0): Not using default mode "416x312" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1280x768" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "640x384" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1280x800" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "640x400" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1152x768" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "576x384" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1152x864" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "576x432" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1400x1050" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "700x525" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1400x1050" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "700x525" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1400x1050" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "700x525" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1400x1050" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "700x525" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1440x900" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "720x450" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1600x1024" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "800x512" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1680x1050" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "840x525" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1920x1200" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "960x600" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1920x1200" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "960x600" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "1920x1440" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "960x720" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "2048x1536" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "2048x1536" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (II) TRIDENT(0): Not using default mode "2048x1536" (width too large for virtual size) (II) TRIDENT(0): Not using default mode "1024x768" (bad mode clock/interlace/doublescan) (**) TRIDENT(0): Virtual size is 1024x768 (pitch 1024) (**) TRIDENT(0): *Mode "1024x768@60": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) TRIDENT(0): Modeline "1024x768@60" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (**) TRIDENT(0): *Mode "800x600@60": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) TRIDENT(0): Modeline "800x600@60" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (**) TRIDENT(0): *Mode "800x600@56": 36.0 MHz, 35.2 kHz, 56.2 Hz (II) TRIDENT(0): Modeline "800x600@56" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (**) TRIDENT(0): *Mode "640x480@60": 25.2 MHz, 31.5 kHz, 60.0 Hz (II) TRIDENT(0): Modeline "640x480@60" 25.20 640 656 752 800 480 490 492 525 -hsync -vsync (**) TRIDENT(0): Default mode "1024x768": 65.0 MHz, 48.4 kHz, 60.0 Hz (II) TRIDENT(0): Modeline "1024x768" 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (**) TRIDENT(0): Default mode "800x600": 40.0 MHz, 37.9 kHz, 60.3 Hz (II) TRIDENT(0): Modeline "800x600" 40.00 800 840 968 1056 600 601 605 628 +hsync +vsync (**) TRIDENT(0): Default mode "800x600": 36.0 MHz, 35.2 kHz, 56.2 Hz (II) TRIDENT(0): Modeline "800x600" 36.00 800 824 896 1024 600 601 603 625 +hsync +vsync (**) TRIDENT(0): Default mode "640x480": 25.2 MHz, 31.5 kHz, 59.9 Hz (II) TRIDENT(0): Modeline "640x480" 25.18 640 656 752 800 480 490 492 525 -hsync -vsync (==) TRIDENT(0): DPI set to (100, 100) (==) TRIDENT(0): Write-combining range (0xf0000000,0x4000000) (II) TRIDENT(0): Initializing int10 (II) TRIDENT(0): Primary V_BIOS segment is: 0xc000 (II) TRIDENT(0): Overriding Horizontal timings. (II) TRIDENT(0): Shadow on (II) TRIDENT(0): H-timing shadow registers: 0xce 0x91 0xa6 0x14 (II) TRIDENT(0): H-timing registers: 0xa3 0x7f 0x7f 0x86 0x83 0x94 (II) TRIDENT(0): V-timing shadow registers: 0x28 0x50 0x01 0x04 0x28 (0xa8) (II) TRIDENT(0): V-timing registers: 0x24 0xf5 0x03 0x29 0xff 0x00 0x24 (II) TRIDENT(0): Setting BIOS Mode Regs: 31 63 for: 1024x768 (II) TRIDENT(0): Found Clock 108.00 n=173 m=22 k=0 (II) TRIDENT(0): Using 1279 scanlines of offscreen memory for area's (II) TRIDENT(0): Using 58724352 bytes of offscreen memory for linear (offset=0x7ff000) (II) TRIDENT(0): Using XFree86 Acceleration Architecture (XAA) (==) TRIDENT(0): Backing store disabled (==) TRIDENT(0): Silken mouse enabled Surely the problem will be in the bios and not in driver. Thanks.
Can you remove your hsync/vrefresh settings in your config file and re-upload a log again without the patch ?
Created attachment 13660 [details] I attach the new log whithout de patch and the hsync/vrefresh settings. Using Christoph Biedl workaround but without the hsync/vrefresh config the xserver also fails but in this case is possible to close the Xserver with Ctrl+Shift+Del.
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.
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
Created attachment 20574 [details] [review] 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.
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" ...........................
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please reopen this bug or file a new report if you continue to experience issues with current releases.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.