Re: [Xpert]tdfx soft-boot hang revisited
Bo Brinkman writes: Several months ago I mentioned that tdfx soft-boot problems seem to have re-appeared. I haven't had time until now to poke around into it. The current behavior (linux kernel 2.4.18-10, XFree86 4.2.0-8 through 10/12/2002 CVS) is that whenever I try to softboot either my Voodoo3 2000 or Voodoo3 3000, the entire OS goes down. We used to have this problem due to improper PCI code (see the archives). No log file ever gets saved, but when I start X remotely, this is what I get: Unfortunately this is completely useless. Please send a scanpci -v output prior to starting X and one just before the BIOS is POSTed. To do that you need to put a breakpoint into the code and run it inside gdb. See xc/programs/Xserver/hw/xfree86/DebuggingHints in the sources for details. Regards, Egbert. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
Hello all, Excuse me for my poor english.. but, i have the problem you are describing. I tried xfree-cvs from saturday, and then i had two problems i hadn't with 4.2.0 (from gentoo): - xfree was very long to first start, when kdm was launched, hard disk working a lot (a sort of font processing ?) - when i first launch the X server there is no problem, but if i switch vt or i restart it, it freezes, and i need to reboot, very annoying :o/... My configuration is a IBM Thinkpad T30: P4m 1.8ghz / 256mo ddr 40Go dd lspci | grep VGA 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] 16mb of ddr memory I attach the X log. (there is no dri in this one, but the problems remains when dri is activated..) Thanks for your hard work. Thomas This is a pre-release version of XFree86, and is not supported in any way. Bugs may be reported to [EMAIL PROTECTED] and patches submitted to [EMAIL PROTECTED] Before reporting bugs in pre-release versions, please check the latest version in the XFree86 CVS repository (http://www.XFree86.Org/cvs) XFree86 Version 4.2.99.1 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 26 September 2002 If the server is older than 6-12 months, or if your card is newer than the above date, look for a newer version before reporting problems. (See http://www.XFree86.Org/) Build Operating System: Linux 2.4.18-wolk3.6.1 i686 [ELF] 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/XFree86.1.log, Time: Thu Oct 10 11:52:58 2002 (==) Using config file: /etc/X11/XF86Config (==) ServerLayout Simple Layout (**) |--Screen Screen 1 (0) (**) | |--Monitor My Monitor (**) | |--Device ATI Xpert XL (**) |--Input Device Keyboard1 (**) Option AutoRepeat 500 30 (**) Option XkbRules xfree86 (**) XKB: rules: xfree86 (**) Option XkbModel rapidaccess2 (**) XKB: model: rapidaccess2 (**) Option XkbLayout fr (**) XKB: layout: fr (==) Keyboard: CustomKeycode disabled (**) |--Input Device UsbMouse (**) |--Input Device InternalMouse (**) FontPath set to /usr/X11R6/lib/X11/fonts/local/,/usr/X11R6/lib/X11/fonts/misc/,/usr/X11R6/lib/X11/fonts/75dpi/:unscaled,/usr/X11R6/lib/X11/fonts/100dpi/:unscaled,/usr/X11R6/lib/X11/fonts/Type1/,/usr/X11R6/lib/X11/fonts/Speedo/,/usr/X11R6/lib/X11/fonts/75dpi/,/usr/X11R6/lib/X11/fonts/100dpi/ (**) RgbPath set to /usr/X11R6/lib/X11/rgb (==) ModulePath set to /usr/X11R6/lib/modules (++) using VT number 8 (II) Open APM successful (II) Module ABI versions: XFree86 ANSI C Emulation: 0.1 XFree86 Video Driver: 0.6 XFree86 XInput driver : 0.3 XFree86 Server Extension : 0.1 XFree86 Font Renderer : 0.3 (II) Loader running on linux (II) LoadModule: bitmap (II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a (II) Module bitmap: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 Module class: XFree86 Font Renderer ABI class: XFree86 Font Renderer, version 0.3 (II) Loading font Bitmap (II) LoadModule: pcidata (II) Loading /usr/X11R6/lib/modules/libpcidata.a (II) Module pcidata: vendor=The XFree86 Project compiled for 4.2.99.1, module version = 1.0.0 ABI class: XFree86 Video Driver, version 0.6 (II) PCI: Probing config type using method 1 (II) PCI: Config type is 1 (II) PCI: stages = 0x03, oldVal1 = 0x, mode1Res1 = 0x8000 (II) PCI: PCI scan (all values are in hex) (II) PCI: 00:00:0: chip 8086,1a30 card , rev 04 class 06,00,00 hdr 00 (II) PCI: 00:01:0: chip 8086,1a31 card , rev 04 class 06,04,00 hdr 01 (II) PCI: 00:1d:0: chip 8086,2482 card 1014,0220 rev 02 class 0c,03,00 hdr 80 (II) PCI: 00:1d:1: chip 8086,2484 card 1014,0220 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1d:2: chip 8086,2487 card 1014,0220 rev 02 class 0c,03,00 hdr 00 (II) PCI: 00:1e:0: chip 8086,2448 card , rev 42 class 06,04,00 hdr 01 (II) PCI: 00:1f:0: chip 8086,248c card , rev 02 class 06,01,00 hdr 80 (II) PCI: 00:1f:1: chip 8086,248a card 1014,0220 rev 02 class 01,01,8a hdr 00 (II) PCI: 00:1f:3: chip 8086,2483 card 1014,0220 rev 02 class 0c,05,00 hdr 00 (II) PCI: 00:1f:5: chip 8086,2485 card 1014,0508 rev 02 class 04,01,00 hdr 00 (II) PCI: 00:1f:6: chip 8086,2486 card 1014,0223 rev 02 class 07,03,00 hdr 00 (II) PCI: 01:00:0: chip 1002,4c57 card 1014,0517 rev 00 class 03,00,00 hdr 00 (II) PCI: 02:00:0: chip 104c,ac55 card 4000, rev 01 class 06,07,00 hdr 82 (II) PCI: 02:00:1: chip 104c,ac55 card 4800, rev 01 class 06,07,00 hdr 82 (II) PCI: 02:02:0: chip 14b9,a504 card 14b9,5000 rev 00 class 02,80,00 hdr 00 (II) PCI: 02:08:0: chip 8086,1031 card 1014,0209 rev 42 class 02,00,00 hdr 00 (II) PCI: End of PCI scan (II) Host-to-PCI bridge: (II) Bus 0: bridge is at (0:0:0), (0,0,6), BCTRL: 0x0008 (VGA_EN is set) (II) Bus 0 I/O range: [0] -1 0
[Xpert]My 6 head PC can be seen here.
http://www.pvv.org/~kim That is me, sitting at my 6 head system in Linux. It is working thanks to this mailing list. So, I wonder if somebody can recommend improvements to my config file, supplied below. F.ex. I would like to have 3d, even though it is not accelerated. Perhaps Mesa? The startup process is somewhat messy and buggy, with 2 boots and 4 startx every time. It is thus: 1. startx Machine hangs, and must be rebooted with ctrl+Alt+Del. Error: (EE) MGA(3): No valid modes found 2. startx X stops. Error: (EE) MGA(3): MGAValidateMode from HALlib found the mode to be invalid. Error: b1901020 Fatal server error: AddScreen/ScreenInit failed for driver 3 3. startx X stops. Error: (WW) MGA(5): Failed to set up write-combining range (0xdb80,0x80) (EE) MGA(5): MGAValidateMode from HALlib found the mode to be invalid. Error: b1901020 Fatal server error: AddScreen/ScreenInit failed for driver 5 4. startx And X finally starts, and works as it should, stable. Kim0 # ** # Refer to the XF86Config(4/5) man page for details about the format of # this file. # ** Section Files RgbPath /usr/X11R6/lib/X11/rgb ModulePath /usr/X11R6/lib/modules FontPath /usr/X11R6/lib/X11/fonts/misc/ FontPath /usr/X11R6/lib/X11/fonts/Speedo/ FontPath /usr/X11R6/lib/X11/fonts/Type1/ FontPath /usr/X11R6/lib/X11/fonts/CID/ FontPath /usr/X11R6/lib/X11/fonts/75dpi/ FontPath /usr/X11R6/lib/X11/fonts/100dpi/ EndSection # ** # Server flags section. # ** Section ServerFlags # Uncomment this to cause a core dump at the spot where a signal is # received. This may leave the console in an unusable state, but # may # provide a better stack trace in the core dump to aid in debugging #NoTrapSignals # Uncomment this to disable the crtlaltbs server abort # sequence # This allows clients to receive this key event. #DontZap # Uncomment this to disable the crtlaltkp_ +=/kp_- mode # switching # sequences. This allows clients to receive these key events. #DontZoom # This allows the server to start up even if the # mouse device can't be opened/initialised. AllowMouseOpenFail EndSection # ** # Input devices # ** # ** # Keyboard section # ** Section InputDevice Identifier Keyboard1 Driver Keyboard Option AutoRepeat 250 30 Option XkbRules xfree86 Option XkbModel pc105 Option XkbLayout no EndSection # ** # Pointer section # ** #Section InputDevice #Identifier Mouse2 #Driver mouse #Option ProtocolPS/2 #Option Device /dev/usbmouse #Option Emulate3Buttons #Option Emulate3Timeout50 #EndSection Section InputDevice Identifier Mouse1 Driver mouse Option ProtocolPS/2 Option Device /dev/psaux Option Emulate3Buttons Option Emulate3Timeout50 EndSection Section Module # This loads the DBE extension module. #Loaddbe # This loads the miscellaneous extensions module, and disables # initialisation of the XFree86-DGA extension within that module. SubSection extmod Option omit xfree86-dga EndSubSection # This loads the Type1 and FreeType font modules Loadtype1 Loadfreetype EndSection # ** # Monitor section # ** # Any number of monitor sections may be present Section Monitor Identifier Generic|High Frequency SVGA, 1024x768 at 70 Hz VendorName Unknown ModelName Unknown # HorizSync is in kHz unless units are specified. # HorizSync may be a comma separated list of discrete values, or a # comma separated list of ranges of values. # NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S # USER MANUAL FOR THE CORRECT NUMBERS. HorizSync 31.5-87.0 # VertRefresh is in Hz unless units are specified. # VertRefresh may be a comma separated list of discrete values, or a # comma separated list of ranges of values. # NOTE: THE VALUES HERE ARE EXAMPLES ONLY. REFER TO YOUR MONITOR'S # USER MANUAL FOR THE CORRECT NUMBERS. VertRefresh
[Xpert]Silicon Motion driver problem
Greetings ;o) Trying to get XFree86 v4.2.1 up and running on my laptop (Panasonic CFM-34) running FreeBSD v4.7. It fails terribly and all I get is a blank screen that I can't kill off (kill -9 on XFree86 via logging on via ssh) won't do it and the only option is shutdown -r. The last few lines of the XFree86 log file reveals: (==) Silicon Motion(0): Write-combining range (0xfd40,0x40) was already clear (==) Silicon Motion(0): Write-combining range (0xfd00,0x40) (II) Silicon Motion(0): Cursor Offset: 003FFC00 Reserved: 003FF800 (II) Silicon Motion(0): TFT Panel Size = 800x600 (II) Silicon Motion(0): vgaHWGetIOBase: hwp-IOBase is 0x03d0, hwp-PIOOffset is 0x (==) Silicon Motion(0): Write-combining range (0xa,0x1) was already clear (II) Loading sub module int10 (II) LoadModule: int10 (II) Reloading /usr/X11R6/lib/modules/libint10.a (II) Silicon Motion(0): initializing int10 (==) Silicon Motion(0): Write-combining range (0xa,0x2) was already clear (II) Silicon Motion(0): Primary V_BIOS segment is: 0xc000 (II) Silicon Motion(0): VESA BIOS function failed Fatal server error: Caught signal 11. Server aborting Does anyone have any ideas on what I can do to get XFree86 up and running? Thanks, Tony ** * Tony Hacche* * ULCC * * 20 Guilford Street * * London WC1N 1DZ* ** * Tel: 020 7692 1440 * * Fax: 020 7504 1035 * * Mob: 07866 623093 * ** There is nothing which has yet been contrived by man, by which so much happiness is produced as by a good tavern or inn. (Samuel Johnson) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
On Tue, Oct 15, 2002 at 11:59:29AM +, Tom wrote: I tried xfree-cvs from saturday, and then i had two problems i hadn't with 4.2.0 (from gentoo): - xfree was very long to first start, when kdm was launched, hard disk working a lot (a sort of font processing ?) - when i first launch the X server there is no problem, but if i switch vt or i restart it, it freezes, and i need to reboot, very annoying :o/... The VT switch problem only occurred on DRI-using setups. What you could try to do to confirm is to ssh into the machine after it has crashed when you switched to a VT and do a lspci -vv. If the Radeon has a BusMaster- flag instead of BusMaster+ and your X is using DRI, it is this specific VT switch lockup. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]My 6 head PC can be seen here.
On Tue, 15 Oct 2002 [EMAIL PROTECTED] wrote: http://www.pvv.org/~kim That is me, sitting at my 6 head system in Linux. It is working thanks to this mailing list. So, I wonder if somebody can recommend improvements to my config file, supplied below. F.ex. I would like to have 3d, even though it is not accelerated. Perhaps Mesa? The startup process is somewhat messy and buggy, with 2 boots and 4 startx every time. It is thus: Sounds as though the second and third cards aren't soft-booted if there is a problem with a previous card. Does X -configure soft boot the cards successfully ? I'm suggesting that X -configure startx might remove at least one step from your sequence. -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
On Tuesday 15 October 2002 10:38, Charl P. Botha wrote: On Tue, Oct 15, 2002 at 11:59:29AM +, Tom wrote: I tried xfree-cvs from saturday, and then i had two problems i hadn't with 4.2.0 (from gentoo): - xfree was very long to first start, when kdm was launched, hard disk working a lot (a sort of font processing ?) - when i first launch the X server there is no problem, but if i switch vt or i restart it, it freezes, and i need to reboot, very annoying :o/... The VT switch problem only occurred on DRI-using setups. What you could try to do to confirm is to ssh into the machine after it has crashed when you switched to a VT and do a lspci -vv. If the Radeon has a BusMaster- flag instead of BusMaster+ and your X is using DRI, it is this specific VT switch lockup. I rerun the test with dri enabled : the steps : - startx go to vt7 - ctrl + alt + f1 go to vt1 - ctrl + alt + f7 go to vt7 I attached the lspci -vv outputs for radeon between the steps, and my XFree.0.log. It seems my problem dont show BusMater-... But the problem remains, the Screen is freezed.. and i cannot do anything reboot. I dont have the problem with 4.2.0 :o/... It seems, it lacks a sort of reinitialisation of the graphics.. (wich is done in 4.2..). Thanks for ur advice. :o). Thomas ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
On Tue, Oct 15, 2002 at 01:12:41PM +, Tom wrote: I rerun the test with dri enabled : the steps : - startx go to vt7 - ctrl + alt + f1 go to vt1 - ctrl + alt + f7 go to vt7 I attached the lspci -vv outputs for radeon between the steps, and my XFree.0.log. I didn't get any attachments with your mail. Could you try again? It seems my problem dont show BusMater-... But the problem remains, the Screen is freezed.. and i cannot do anything reboot. I dont have the problem with 4.2.0 :o/... It seems, it lacks a sort of reinitialisation of the graphics.. (wich is done in 4.2..). The busmastering VT-switch lockup was present in 4.2 as well. I'm beginning to think that the problem that you are seeing is something else altogether, but just as serious. :) -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
Oups, i forget the attachment... then now they are ;o). On Tuesday 15 October 2002 11:37, Charl P. Botha wrote: On Tue, Oct 15, 2002 at 01:12:41PM +, Tom wrote: I rerun the test with dri enabled : the steps : - startx go to vt7 - ctrl + alt + f1 go to vt1 - ctrl + alt + f7 go to vt7 I attached the lspci -vv outputs for radeon between the steps, and my XFree.0.log. I didn't get any attachments with your mail. Could you try again? It seems my problem dont show BusMater-... But the problem remains, the Screen is freezed.. and i cannot do anything reboot. I dont have the problem with 4.2.0 :o/... It seems, it lacks a sort of reinitialisation of the graphics.. (wich is done in 4.2..). The busmastering VT-switch lockup was present in 4.2 as well. I'm beginning to think that the problem that you are seeing is something else altogether, but just as serious. :) Before startx : 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 0517 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B+ Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 3000 [size=256] Region 2: Memory at d010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2,x4 Command: RQ=0 SBA+ AGP- 64bit- FW- Rate=none Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- After startx : 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 0517 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B+ Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 3000 [size=256] Region 2: Memory at d010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2,x4 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x4 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- After switch to vt 1 (alt+ctrl+F1) : 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 0517 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B+ Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 3000 [size=256] Region 2: Memory at d010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K] Capabilities: [58] AGP version 2.0 Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2,x4 Command: RQ=31 SBA+ AGP+ 64bit- FW- Rate=x4 Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=0 PME- Switch to X (vt 7) : 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M7 LW [Radeon Mobility 7500] (prog-if 00 [VGA]) Subsystem: IBM: Unknown device 0517 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR+ FastB2B+ Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 66 (2000ns min), cache line size 08 Interrupt: pin A routed to IRQ 11 Region 0: Memory at e800 (32-bit, prefetchable) [size=128M] Region 1: I/O ports at 3000 [size=256] Region 2: Memory at d010 (32-bit, non-prefetchable) [size=64K] Expansion ROM at unassigned [disabled] [size=128K]
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
On Tue, Oct 15, 2002 at 01:42:09PM +, Tom wrote: Oups, i forget the attachment... then now they are ;o). Okay, this is definitely not the BusMastering VT-switch lockup we used to have, but it's still bad. If you want to solve this problem, you have to build a static X and attach to the running process when it freezes so that you can get a backtrace which will give you clues on where to start looking. You could also try one of the dri.sf.net snapshots to see if that has the same behaviour. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
Euh.. I would like to help, but could u explain me the steps? ;o) How can i build static X? how can i attach to the running process? (gdb) What are the commands and the important information.. I tried the dri.sourceforge.net drivers, but i have a blank screen.. On Tuesday 15 October 2002 11:52, Charl P. Botha wrote: On Tue, Oct 15, 2002 at 01:42:09PM +, Tom wrote: Oups, i forget the attachment... then now they are ;o). Okay, this is definitely not the BusMastering VT-switch lockup we used to have, but it's still bad. If you want to solve this problem, you have to build a static X and attach to the running process when it freezes so that you can get a backtrace which will give you clues on where to start looking. You could also try one of the dri.sf.net snapshots to see if that has the same behaviour. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
On Tue, Oct 15, 2002 at 02:05:53PM +, Tom wrote: I would like to help, but could u explain me the steps? ;o) How can i build static X? In your host.conf (if I remember correctly, it could also be host.def) you can configure for building a static XFree86. how can i attach to the running process? (gdb) After it's crashed, you ssh into the machine, use ps or top to find the pid of the running static XFree86. Then you do: gdb /path/to/the/static/XFree86/that/you/run pid (gdb) bt That last command will generate a backtrace and this should give you more information about where the server is hanging. I tried the dri.sourceforge.net drivers, but i have a blank screen.. We could try to diagnose this if you want to. -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VTswitch
On Die, 2002-10-15 at 14:17, Charl P. Botha wrote: On Tue, Oct 15, 2002 at 02:05:53PM +, Tom wrote: I tried the dri.sourceforge.net drivers, but i have a blank screen.. We could try to diagnose this if you want to. This has been hashed to death on dri-devel. It's a binary incompatibility that can be worked around by using libxaa from DRI CVS. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
On Tue, Oct 15, 2002 at 02:24:52PM +0200, Michel Dänzer wrote: On Die, 2002-10-15 at 14:17, Charl P. Botha wrote: On Tue, Oct 15, 2002 at 02:05:53PM +, Tom wrote: I tried the dri.sourceforge.net drivers, but i have a blank screen.. We could try to diagnose this if you want to. This has been hashed to death on dri-devel. It's a binary incompatibility that can be worked around by using libxaa from DRI CVS. Aaaah... I didn't realise it was this problem. Tom, if you don't want to build DRI from CVS, you can grab the radeon resume driver tarball from my pages at cpbotha.net/dri_resume.html and use the libxaa.a from there with a driver tarball from dri.sf.net. You could also test with my driver tarball instead just for fun. :) -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Double mouse pointer (nv geforce3ti dvi)
With 4.2.1, the nv driver *finally* produces a correct image on my setup. Only one small bug remains: The mouse pointer. It is duplicated and half the right size. Actually, the duplication effect looks more to be a case of every other bit being drawn 16 pixels too far to the right. The duplicates are not exact copies. Is this known/fixed? Is there a workaround? Is there anything I can do to help? Driver nv Option FlatPanel -- Björn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
Why does ur driver is not included in cvs? :o/ it should resolve a lot of problem !! ;o) On Tuesday 15 October 2002 12:36, Charl P. Botha wrote: On Tue, Oct 15, 2002 at 02:24:52PM +0200, Michel Dänzer wrote: On Die, 2002-10-15 at 14:17, Charl P. Botha wrote: On Tue, Oct 15, 2002 at 02:05:53PM +, Tom wrote: I tried the dri.sourceforge.net drivers, but i have a blank screen.. We could try to diagnose this if you want to. This has been hashed to death on dri-devel. It's a binary incompatibility that can be worked around by using libxaa from DRI CVS. Aaaah... I didn't realise it was this problem. Tom, if you don't want to build DRI from CVS, you can grab the radeon resume driver tarball from my pages at cpbotha.net/dri_resume.html and use the libxaa.a from there with a driver tarball from dri.sf.net. You could also test with my driver tarball instead just for fun. :) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VT switch
On Tue, Oct 15, 2002 at 03:01:35PM +, Tom wrote: Why does ur driver is not included in cvs? :o/ it should resolve a lot of problem !! ;o) The driver from my pages is not a pure DRI build. It includes code by me for suspending/resuming Radeons and is thus not recommended for everyone. However, if it works for you, by all means use it. :) -- charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Probable return of Radeon, R128 XFree86 crash at VTswitch
On Die, 2002-10-15 at 15:12, Charl P. Botha wrote: On Tue, Oct 15, 2002 at 03:01:35PM +, Tom wrote: Why does ur driver is not included in cvs? :o/ it should resolve a lot of problem !! ;o) No, the problem is only with the binary snapshots, if you build yourself from CVS it should work fine. -- Earthling Michel Dänzer (MrCooper)/ Debian GNU/Linux (powerpc) developer XFree86 and DRI project member / CS student, Free Software enthusiast ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]rage pro (16mb) symbol errors
So, anyone have any ideas why the the cvs version I pulled Oct 12 might cause my box to lock up? I'm trying to get dual head working with a redeon ve (retail 32mb) and a rage pro (16mb). Previous efforts, the box would lock up if I had both the radeon and rage configured. In the case of the cvs version, the box locks up with a previously working config for single head radeon ve. I'll get cvs again if anyone thinks this will make a difference, but it's not a pretty site to have to power this box down. No log file is generated at all, if that's any indicator. Could this because by a conflict within hardware? Any assistance would be appreciated. Here's the output of lscpi currently: 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:04.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) 00:04.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:04.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:04.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:09.0 Multimedia video controller: Brooktree Corporation Bt878 Video Capture (rev 02) 00:09.1 Multimedia controller: Brooktree Corporation Bt878 Audio Capture (rev 02) 00:0a.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller 00:0b.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro 215GP (rev 5c) 00:0c.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon VE QY -- Until later: Geoffrey [EMAIL PROTECTED] I didn't have to buy my radio from a specific company to listen to FM, why doesn't that apply to the Internet (anymore...)? ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Sun(Sony)GDM-1662B
HI Has anyone actually got this one going... I've seen posts that claim to have working modelines on various websites but none seem to work. cheers Allan -- Linux: Because a PC is a terrible thing to waste. (By [EMAIL PROTECTED], Mark Komarinski) -- Linux: Because a PC is a terrible thing to waste. (By [EMAIL PROTECTED], Mark Komarinski) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]!! Correction for i810 driver !!
Actually...
I am not sure that reg 0x6 will be set in all cases. I may only be
programmed if there is a TVout controller present in the system. Doing
it this way is safer. Maybe someone looking for a task can make a diff out
of this and submit it to the patches list?
-Matt
File : xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
Somewhere near line 1522
unsigned int temp=0;
/* OVRACT Register */
temp = INREG(0x6);
if(temp) {
i810Reg-OverlayActiveStart = (temp16) - 31;
i810Reg-OverlayActiveEnd = (temp 0x3ff) - 31;
} else {
i810Reg-OverlayActiveStart = mode-CrtcHTotal - 32;
i810Reg-OverlayActiveEnd = mode-CrtcHDisplay - 32;
}
-Original Message-
From: Sebastien BASTARD [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 15, 2002 2:50 AM
To:
Subject: [Xpert]!! Correction for i810 driver !!
Hello,
I have a i810 controller with crontel 7007 out tv. With the lastest
Xfree 4.2.1, the Video Direct Render didn't work correctly.
In 640x480, the Video Direct Render print half image on the screen. And
with 800x600, i hadn't picture.
While 3 weeks, i searched a solution. I find one on a e-mail (but i
forgot the name of the person who posting the test solution).
I tested, and it work great !
I don't how it work (the solution), but it works.
I tested in 640x480, and 800x600 resolution, 24 bits and 16 bits.
Someone can modify the CSV driver 810 file ?
File : xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
removed (line 1522):
/* OVRACT Register */
i810Reg-OverlayActiveStart = mode-CrtcHTotal - 32;
i810Reg-OverlayActiveEnd = mode-CrtcHDisplay - 32;
added (1476) :
unsigned int temp=0;
added (line 1522) :
temp = INREG(0x6);
i810Reg-OverlayActiveStart = (temp16) - 31;
i810Reg-OverlayActiveEnd = (temp 0x3ff) - 31;
P.S : Sorry for my bad english ... and sorry because i didn't used the
diff program
French programmer
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]How is modeline chosen?
I just got my new 1280x1024 17 flatscreen set up, and it looked like hell, with moires, aliased vertical lines, etc.. As seems to be the case after running XF86Config originally, I had several 1280x1024 ModeLines in my XF86Config file. The closest modeline looked like this: # 1280x1024 @ 61 Hz, 64.2 kHz hsync Modeline 1280x1024 110 1280 1328 1512 1712 1024 1025 1028 1054 Since the flat screen really wants to have *exactly* the right pixel frequency, as a shot in the dark I added these lines right above that one: Modeline 1280x1024 108 1280 1328 1512 1712 1024 1025 1028 1054 Modeline 1280x1024 108.5 1280 1328 1512 1712 1024 1025 1028 1054 Modeline 1280x1024 109 1280 1328 1512 1712 1024 1025 1028 1054 Modeline 1280x1024 109.5 1280 1328 1512 1712 1024 1025 1028 1054 I changed only the pixel clock - it's close enough that the other parameters didn't seem to need adjustment - and things look very good now.. right now my display says it's getting 63.9 kHz horzontal sync - almost perfect. (The display wants 63.98 H and 60.02 V.) My question is: In the presence of several 1280x1024 modelines, how is the modeline chosen? Is XF86 even using the XF86Config file? The XF86COnfig-4 files doesn't have any modelines in it. I don't see anything in the log file except (II) NVIDIA(0): Setting mode 1280x1024 This is XFree86 4.2.0, the one that comes with RedHat 7.3, and the NVidia-supplied driver to a Geforce2. Thanks, -W Sanders www.wsanders.net __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos More http://faith.yahoo.com ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Double mouse pointer (nv geforce3ti dvi)
On Tue, 15 Oct 2002, Björn Stenberg wrote: With 4.2.1, the nv driver *finally* produces a correct image on my setup. Only one small bug remains: The mouse pointer. It is duplicated and half the right size. Actually, the duplication effect looks more to be a case of every other bit being drawn 16 pixels too far to the right. The duplicates are not exact copies. Is this known/fixed? Is there a workaround? Is there anything I can do to help? Driver nv Option FlatPanel ??? If there is flat panel support in 4.2.1, I don't know how it got there. I didn't put it there. The flat panel support I added was in CVS only. The artifact you describe sounds like what you get when you run the nv driver after running the nvidia driver - a problem which doesn't exist in CVS (or if you don't run the nvidia driver). But as far as I know, DFP isn't supported in 4.2.1 in the first place. Mark. ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Double mouse pointer (nv geforce3ti dvi)
Mark Vojkovich wrote: The artifact you describe sounds like what you get when you run the nv driver after running the nvidia driver Ah, that's exactly what I did. Silly me, I should have tested from cold. But as far as I know, DFP isn't supported in 4.2.1 in the first place. Ok, back to nvidia for a while longer then. Thank you for the information. -- Björn ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Patches for xfree86 cyrix (NatSemi GX1) driver
Hi, I have been playing with Alan Cox's version
of the xfree86/drivers/cyrix (Geode) video driver
on a NatSemi Centaurus reference platform (Geode
GX1 cpu) running FreeBSD. The cyrix driver in the
CVS tree at xfree86.org appears not to have been
modified for some 9 months, except for makefile
maintenance, and it does not detect the hardware
in my Centaurus environment. Alan notes this driver
``had previously in part worked by accident''
and ``had some fairly incomplete looking areas''.
See also (I got Alan's version from the redhat
url):
-
From: Mike A. Harris [EMAIL PROTECTED]
Subject: [Xpert]Re: Cyrix Geode/Kahlua problems...
Date: Tue, 10 Sep 2002 02:52:37 +0200
From: Erich Schubert [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Cyrix Geode/Kahlua problems...
http://people.redhat.com/alan
---
From: Alex Pavloff [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: [Xpert]Re: Cyrix Geode/Kahlua problems...
See also http://www.eason.com/linux, which contains my experiences with
National's framebuffer drivers. Also present there are National's
official XFree86 drivers.
-
I had to make the following patches to Alan's version
of the driver:
* To make X -configure not coredump:
--- /usr/brucem/X_wrk/cyrix_redhat/cyrix_driver.c Wed Aug 28 09:07:23 2002
+++ cyrix_driver.c Tue Oct 15 12:11:17 2002
@@ -569,6 +569,11 @@
*/
pCyrix = CYRIXPTR(pScrn);
+pCyrix-pEnt = xf86GetEntityInfo(pScrn-entityList[0]);
+
+if (pCyrix-pEnt-location.type != BUS_PCI)
+ return FALSE;
+
if (flags PROBE_DETECT) {
CYRIXProbeDDC(pScrn, pCyrix-pEnt-index);
return TRUE;
Without this patch in CYRIXPreInit(ScrnInfoPtr
pScrn, int flags) X -configure (PROBE_DETECT)
will always coredump due to the uninitialized
pEnt field.
In my environment, ``Option NoCompression''
must be enabled (uncommented) in the -configure
generated XF86Config file's ``Section Device''.
I'm assuming this is because the Geode Display
Controller Frame Buffer Start Offset register
(DC_FB_ST_OFFSET, GX_BASE+8310), in my environment
(likely initialized by the BIOS?), is nonzero (it
is, I've checked). The Geode GX1 cpu manual doc
for this register notes When this register is
programmed to a nonzero value, the compression
logic should be disabled. The video hangs if
compression is enabled, at least for me. One
check to avoid hanging is this patch to check for
a non-zero DC_FB_ST_OFFSET in CyrixInit(ScrnInfoPtr
pScrn, DisplayModePtr mode), file cyrix_helper.c:
--- /usr/brucem/X_wrk/cyrix_redhat/cyrix_helper.c Tue Aug 27 09:43:01 2002
+++ cyrix_helper.c Tue Oct 15 12:54:50 2002
@@ -332,6 +332,7 @@
and line-dirty flagging seem to have been solved now. */
if (pCyrix-NoCompress == FALSE
+ (0 == GX_REG(DC_FB_ST_OFFSET))
mode-CrtcVDisplay == pScrn-virtualY
mode-CrtcHDisplay == pScrn-virtualX
)
(DC_FB_ST_OFFSET isn't stored in CYRIXPrivate as
far as I can see.) Should an error message be
logged when the compression option is not enabled
because of this situation? Disabling compression
is a bit troublesome because the manual claims
compression reduces display controller memory load
by as much as 20:1... OTOH, why is my framebuffer
at a non-zero offset?
* Are Alan's changes (reasonably extensive) to be
merged with the CVS? (if so the first patch above,
at least, is likely required). This driver works
on NatSemi's ref platform, while the cvs driver did
not...
* I'm assuming that the cyrix driver in the CVS
tree is in routine use, however, I wonder if it
works with National's BIOS (because it does not
detect any devices on the NatSemi Centaurus).
Is anybody else succesfully using the CVS cyrix
driver code with the GX1 and the National BIOS?
I'm not sure I understand all the BIOS dependency
issues...
* Is anyone working on the cyrix driver currently?
What is the future of this driver, especially wrt
to the official NatSemi drivers?
* Can anyone interested in, or knowledgeble about,
this driver, who has any insight or any advice
regarding it, give a ping? Thanks!
- bruce
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
Re: [Xpert]Patches for xfree86 cyrix (NatSemi GX1) driver
You could try using the geode driver which is now in the XFree86 CVS.
Alan.
On Tue, Oct 15, 2002 at 01:46:50PM -0700, Bruce R. Montague wrote:
Hi, I have been playing with Alan Cox's version
of the xfree86/drivers/cyrix (Geode) video driver
on a NatSemi Centaurus reference platform (Geode
GX1 cpu) running FreeBSD. The cyrix driver in the
CVS tree at xfree86.org appears not to have been
modified for some 9 months, except for makefile
maintenance, and it does not detect the hardware
in my Centaurus environment. Alan notes this driver
``had previously in part worked by accident''
and ``had some fairly incomplete looking areas''.
See also (I got Alan's version from the redhat
url):
-
From: Mike A. Harris [EMAIL PROTECTED]
Subject: [Xpert]Re: Cyrix Geode/Kahlua problems...
Date: Tue, 10 Sep 2002 02:52:37 +0200
From: Erich Schubert [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Cyrix Geode/Kahlua problems...
http://people.redhat.com/alan
---
From: Alex Pavloff [EMAIL PROTECTED]
To: '[EMAIL PROTECTED]' [EMAIL PROTECTED]
Subject: [Xpert]Re: Cyrix Geode/Kahlua problems...
See also http://www.eason.com/linux, which contains my experiences with
National's framebuffer drivers. Also present there are National's
official XFree86 drivers.
-
I had to make the following patches to Alan's version
of the driver:
* To make X -configure not coredump:
--- /usr/brucem/X_wrk/cyrix_redhat/cyrix_driver.c Wed Aug 28 09:07:23 2002
+++ cyrix_driver.c Tue Oct 15 12:11:17 2002
@@ -569,6 +569,11 @@
*/
pCyrix = CYRIXPTR(pScrn);
+pCyrix-pEnt = xf86GetEntityInfo(pScrn-entityList[0]);
+
+if (pCyrix-pEnt-location.type != BUS_PCI)
+ return FALSE;
+
if (flags PROBE_DETECT) {
CYRIXProbeDDC(pScrn, pCyrix-pEnt-index);
return TRUE;
Without this patch in CYRIXPreInit(ScrnInfoPtr
pScrn, int flags) X -configure (PROBE_DETECT)
will always coredump due to the uninitialized
pEnt field.
In my environment, ``Option NoCompression''
must be enabled (uncommented) in the -configure
generated XF86Config file's ``Section Device''.
I'm assuming this is because the Geode Display
Controller Frame Buffer Start Offset register
(DC_FB_ST_OFFSET, GX_BASE+8310), in my environment
(likely initialized by the BIOS?), is nonzero (it
is, I've checked). The Geode GX1 cpu manual doc
for this register notes When this register is
programmed to a nonzero value, the compression
logic should be disabled. The video hangs if
compression is enabled, at least for me. One
check to avoid hanging is this patch to check for
a non-zero DC_FB_ST_OFFSET in CyrixInit(ScrnInfoPtr
pScrn, DisplayModePtr mode), file cyrix_helper.c:
--- /usr/brucem/X_wrk/cyrix_redhat/cyrix_helper.c Tue Aug 27 09:43:01 2002
+++ cyrix_helper.c Tue Oct 15 12:54:50 2002
@@ -332,6 +332,7 @@
and line-dirty flagging seem to have been solved now. */
if (pCyrix-NoCompress == FALSE
+ (0 == GX_REG(DC_FB_ST_OFFSET))
mode-CrtcVDisplay == pScrn-virtualY
mode-CrtcHDisplay == pScrn-virtualX
)
(DC_FB_ST_OFFSET isn't stored in CYRIXPrivate as
far as I can see.) Should an error message be
logged when the compression option is not enabled
because of this situation? Disabling compression
is a bit troublesome because the manual claims
compression reduces display controller memory load
by as much as 20:1... OTOH, why is my framebuffer
at a non-zero offset?
* Are Alan's changes (reasonably extensive) to be
merged with the CVS? (if so the first patch above,
at least, is likely required). This driver works
on NatSemi's ref platform, while the cvs driver did
not...
* I'm assuming that the cyrix driver in the CVS
tree is in routine use, however, I wonder if it
works with National's BIOS (because it does not
detect any devices on the NatSemi Centaurus).
Is anybody else succesfully using the CVS cyrix
driver code with the GX1 and the National BIOS?
I'm not sure I understand all the BIOS dependency
issues...
* Is anyone working on the cyrix driver currently?
What is the future of this driver, especially wrt
to the official NatSemi drivers?
* Can anyone interested in, or knowledgeble about,
this driver, who has any insight or any advice
regarding it, give a ping? Thanks!
- bruce
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Issues with X cvs
Hi I have just downloaded and built (several times) X cvs I have some issues On my current build (which generally works) The mouse is big and red and cant be changed I get messages related Xlib not supporting my locale #, which is 1so 889915 On my last build which I had to revert On nearly every module I get errors while loading On GL modules it is various unresolved symbol errors On all driver modules I get with nv as an example nv driver needs nvmoduleData The build that is working by mistake I think I must have set it to compile all the drivers inside the server My system is RH7.3 base Glibc and gcc from RH8 (glibc-2.2.93 and gcc3.2) Help appreciated -- Linux, Gnome what more do you need http://www.redtux.demon.co.uk ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]How is modeline chosen?
Title: RE: [Xpert]How is modeline chosen? You can toggle trough multiple modes with same resolution by naming them differently. Those ... labels are (freeform?) strings. This means you can e.g. have a 640x480i and a 640x480p timing, where the appended characters might mean for your individual setup interlaced and progressive mode. The real desktop resolution is encoded in the numeric data. -Alex. -Original Message- From: Mark Vojkovich [mailto:[EMAIL PROTECTED]] Sent: Tuesday, October 15, 2002 22:19 To: [EMAIL PROTECTED] Subject: Re: [Xpert]How is modeline chosen? On Tue, 15 Oct 2002, Spammers Must Die wrote: I just got my new 1280x1024 17 flatscreen set up, and it looked like hell, with moires, aliased vertical lines, etc.. As seems to be the case after running XF86Config originally, I had several 1280x1024 ModeLines in my XF86Config file. The closest modeline looked like this: # 1280x1024 @ 61 Hz, 64.2 kHz hsync Modeline 1280x1024 110 1280 1328 1512 1712 1024 1025 1028 1054 Since the flat screen really wants to have *exactly* the right pixel frequency, as a shot in the dark I added these lines right above that one: Modeline 1280x1024 108 1280 1328 1512 1712 1024 1025 1028 1054 Modeline 1280x1024 108.5 1280 1328 1512 1712 1024 1025 1028 1054 Modeline 1280x1024 109 1280 1328 1512 1712 1024 1025 1028 1054 Modeline 1280x1024 109.5 1280 1328 1512 1712 1024 1025 1028 1054
[Xpert]ati driver doesn't work with some laptop LCD screens
Hey all. I have a Dell Inspiron 5000e with an ATI R128 M3: drm0@pci1:0:0: class=0x03 card=0x00cc1028 chip=0x4c461002 rev=0x02 hdr=0x00 vendor = 'ATI Technologies' device = 'Rage Mobility M3 AGP 2x' class= display subclass = VGA Out of the box xf86cfg with X server 4.2.1 does not work claiming that there are no suitable video modes. If I add the following lines to my XF86Config file then X is a bit happier and finds valid 1600x1200 and 1440x1050 modes: Section Monitor Identifier Monitor0 VendorName Monitor Vendor ModelNameMonitor Model # XXX: bogus HorizSync28.0 - 90.0 VertRefresh 50.0 - 62.0 EndSection I have been using these fake monitor rates since about X 4.0.2 and was hoping that 4.2.1 would be able to handle the LCD on its own now. :-) I can provide the full XFree86.log file if needed. Here's a few excerpts related to the LCD screen: (--) R128(0): Chipset: ATI Rage 128 Mobility LF (AGP) (ChipID = 0x4c46) (--) R128(0): Linear framebuffer at 0xf800 (--) R128(0): MMIO registers at 0xf410 (==) R128(0): Write-combining range (0xf410,0x8) was already clear (--) R128(0): VideoRAM: 16384 kByte (128-bit SDR SGRAM 1:1) (**) R128(0): Using flat panel for display (II) R128(0): Panel size: 1600x1200 (II) R128(0): Panel ID: Toshiba LTM15C162 (II) R128(0): Panel Type: Color, Single, TFT (II) R128(0): Panel Interface: LVDS (II) R128(0): PLL parameters: rf=2700 rd=60 min=12500 max=25000; xclk=10500 Thanks for any help. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
[Xpert]Sync Out of Range when I switch to a VT
Hi, I am having a problem with my display. I am running XFree86-4.2.1 on Mandrake 9.0 and tried using the radeon, ati, and ati.2 driver for my Radeon 64MB DDR VIVO on a Samsung SyncMaster 753DF Monitor. It works fine if a tv-out cable isn't connected to my card. However, whenever I hook a tv-out cable to the card and connect it to a TV and reboot, I cannot switch to a VT by pressing CTRL-ALT-F3. Instead my monitor displays Sync Out of Range. I hit CTRL-ALT-F7 to get back to my X display and it works fine on the monitor but displays nothing on the TV. But wait, it gets stranger. If I use the vesa driver for my device in XF86Config-4, I can switch back and forth between the X Display and VTs by using the CTRL-AL-F3/F7. However, the vesa driver looks a little less crisp on my monitor and flickers too much in X. It looks great on the tv though when I switch to a VT and run Xine -V SyncFB foo.avi or mplayer -vo fbdev foot.avi. How can I use the radeon or ati driver to make this work? What am I doing wrong? I had no problems configuring this to work right out of the box with Mandrake 8.1 and 8.2 using the default setup that XFDrake configured. I've tried using the experimental driver, ati.2 but no luck either. I've also tried using atitvout but cannot get it to work. It sees a tv and and monitor attached to my card but locks when I enable them using the radeon driver. I've attached my XF86Config-4 file. If anyone can figure this one out. Thanks.This is driving me crazy trying to debug. TJ XF86Config-4 Description: Binary data
Re: [Xpert]Sun(Sony)GDM-1662B - fixed frequency monitor
What I should hav included was that this is a composite sync monitor that uses the SOny GDM 1662 Trinitron tube (the difference between the 1662 and 1662B tubes is one is for the southern hemisphere. cheers Allan . On Wed, 2002-10-16 at 00:40, Allan Klinbail wrote: HI Has anyone actually got this one going... I've seen posts that claim to have working modelines on various websites but none seem to work. cheers Allan -- Linux: Because a PC is a terrible thing to waste. (By [EMAIL PROTECTED], Mark Komarinski) -- Linux: Because a PC is a terrible thing to waste. (By [EMAIL PROTECTED], Mark Komarinski) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert -- Linux: Because a PC is a terrible thing to waste. (By [EMAIL PROTECTED], Mark Komarinski) ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
