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
Re: [Xpert]tdfx soft-boot hang revisited
Egbert Eich wrote: > 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. Sorry if I'm being an idiot, but could you give me a bit more of a hint about where I should stop the execution? Is this in the TDFXProbe code or in the int10 module? I didn't find any comments in either place that made it totally obvious to me that the BIOS is about to be POSTed. ;) I can't seem to make the module-aware gdb work either, but I'll just add a call to one of the dummy break functions in the appropriate place, since I don't really need to dig around in gdb. FWIW, it looks like we are actually getting a SIGFPE, which is not what I expected... Also note that before X ever runs, this is what scanpci -v gives for this card: pci bus 0x cardnum 0x0a function 0x00: vendor 0x121a device 0x0005 3Dfx Interactive, Inc. Voodoo 3 CardVendor 0x121a card 0x0036 (3Dfx Interactive, Inc. Voodoo3) STATUS0x8090 COMMAND 0x CLASS 0x03 0x00 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xc400 addr 0xc400 MEM BASE1 0xca08 addr 0xca00 MEM PREFETCHABLE BASE2 0xb001 addr 0xb000 I/O BASEROM 0xc9ff addr 0xc9ff not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x05 BYTE_00x01 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 Notice that BASEROM doesn't look crazy like it used to... It used to be left set to 0x. I assume that something has changed in the kernel which causes the BASEROM to be set in this way, because 0x is the default value, and I assume it would stay there unless intentionally changed. Here is the scanpci -v output for the primary card, for comparison (Note that it is an AGP card). pci bus 0x0001 cardnum 0x00 function 0x00: vendor 0x121a device 0x0005 3Dfx Interactive, Inc. Voodoo 3 CardVendor 0x121a card 0x003a (3Dfx Interactive, Inc. Voodoo3 AGP) STATUS0x80b0 COMMAND 0x0003 CLASS 0x03 0x00 0x00 REVISION 0x01 BIST 0x00 HEADER 0x00 LATENCY 0x00 CACHE 0x00 BASE0 0xc600 addr 0xc600 MEM BASE1 0xce08 addr 0xce00 MEM PREFETCHABLE BASE2 0xd801 addr 0xd800 I/O BASEROM 0xcdff addr 0xcdff not-decode-enabled MAX_LAT 0x00 MIN_GNT 0x00 INT_PIN 0x01 INT_LINE 0x0b BYTE_00x01 BYTE_1 0x00 BYTE_2 0x00 BYTE_3 0x00 I will post complete scanpci -v info once I figure out where to put my breakpoint to generate the other info that Egbert wanted. -- William "Bo" Brinkman [EMAIL PROTECTED] Princeton Computer Science http://www.derandomized.org/ -- You have to *live* in the Hilbert space! -- Prof. Andy Yao ___ 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
[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" ModelName"Monitor 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
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]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]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]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]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
Re: [Xpert]My 6 head PC can be seen here.
> On Tue, 15 Oct 2002 [EMAIL PROTECTED] wrote: > > > > 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. Yes, that actually worked. Somewhat messy and slow, but still much faster and cleaner than what I had. Thank you. Kim0 ___ Xpert mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/xpert
RE: [Xpert]!! Correction for i810 driver !!
Egbert,
Actually... I'm thinking there is a problem with this way too. We need
another "if" in there. i.e.
if((tv is on) && (vbios left a set of TV timings for us)) {
use TV regs;
} else {
use crt regs;
}
Otherwise we might end up using the TV timings even when the display is not
on
the TV (depending on what the vbios does when using CRT in a system that has
a TV controller).
Check the LCDTV_C register (offset 0x60018) bit 31. If it is set then
the TV is in use. So try this one:
File : xc/programs/Xserver/hw/xfree86/drivers/i810/i810_driver.c
Somewhere near line 1522
unsigned int lcdtv_c=0;
unsigned int tv_htotal=0;
/* OVRACT Register */
lcdtv_c = INREG(0x60018);
tv_htotal = INREG(0x6);
if((lcdtv_c & 0x8000) && (tv_htotal)) {
i810Reg->OverlayActiveStart = (temp>>16) - 31;
i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31;
} else {
i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32;
i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32;
}
-Original Message-
From: Egbert Eich [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, October 15, 2002 10:44 AM
To: [EMAIL PROTECTED]
Subject: RE: [Xpert]!! Correction for i810 driver !!
Sottek, Matthew J writes:
> 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?
I've checked with the docs and it looks like this patch may be
correct. I'll test it in my i810 and submit it if I don't see
any side effects.
Thanks to both Sebastien and matt!
Regards,
Egbert.
>
> -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 = (temp>>16) - 31;
> i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31;
>} else {
> i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32;
> i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32;
>}
>
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
___
Xpert mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/xpert
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 > > 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? I think the selection criteria is as follows: Use the mode in the XF86Config file unless it falls outside of the monitor specs listed in the XF86Config. If no such mode exists, then it goes to the pool of modes internal to XFree86. From that pool, it picks the highest refresh rate mode that falls within the monitor specs. If you have multiple modes by the same name in the XF86Config file, it probably uses the last one. Mark. ___ 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]!! Correction for i810 driver !!
Sottek, Matthew J writes:
> 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?
I've checked with the docs and it looks like this patch may be
correct. I'll test it in my i810 and submit it if I don't see
any side effects.
Thanks to both Sebastien and matt!
Regards,
Egbert.
>
> -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 = (temp>>16) - 31;
> i810Reg->OverlayActiveEnd = (temp & 0x3ff) - 31;
>} else {
> i810Reg->OverlayActiveStart = mode->CrtcHTotal - 32;
> i810Reg->OverlayActiveEnd = mode->CrtcHDisplay - 32;
>}
>
___
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]My 6 head PC can be seen here.
Cool setup, perhaps you could remove the chassis from each monitor in order to make them stand nearer to each other? I had similar problems with my multihead setup. The second seemed not to be initialized when first starting the X server. When I booted my system the second screen was totally black. Starting startx the first time failed. But after that first time the second head wasn't black anymore but showed some two-line VGA-BIOS info at the top. When the second head woke up from black-nothing into show-bios-info-mode startx always worked out. I was able to make this whole thing work from the very beginning by enabling the console on my second head, using fbcon. Then startx succeeded the first time. To me it seems that this must be because the card wasn't booted or initialized by the BIOS the first time I called startx. Fbcon seemed to initialize/boot the card. Good luck and Regards, Mikael Olenfalk [EMAIL PROTECTED] > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf > Of [EMAIL PROTECTED] > Sent: den 15 oktober 2002 12:14 > To: [EMAIL PROTECTED] > Subject: [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 server abort > # sequence > # This allows clients to receive this key event. > #DontZap > > # Uncomment this to disable the / 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 "Protocol""PS/2" > #Option "Device" "/dev/usbmouse" > #Option "Emulate3Buttons" > #Option "Emulate3Timeout""50" > #EndSection > > > Section "InputDevice" > Identifier "Mouse1" > Driver
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 = (temp>>16) - 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 = (temp>>16) - 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]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]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
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]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 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
[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
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
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: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 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 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
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- SERR- [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= 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- SERR- [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- SERR- [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- SERR- [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- 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: 10 October 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.20-pre10-ac1 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.0.log", Time: Tue Oct 15 12:57:47 2002 (==) Using config file: "/etc/X1
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
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]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 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
[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
[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 server abort # sequence # This allows clients to receive this key event. #DontZap # Uncomment this to disable the / 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 "Protocol""PS/2" #Option "Device" "/dev/usbmouse" #Option "Emulate3Buttons" #Option "Emulate3Timeout""50" #EndSection Section "InputDevice" Identifier "Mouse1" Driver "mouse" Option "Protocol""PS/2" Option "Device" "/dev/psaux" Option "Emulate3Buttons" Option "Emulate3Timeout""50" EndSection Section "Module" # This loads the DBE extension module. #Load"dbe" # 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 Load"type1" Load"freetype" 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 EXAMPL
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), B
[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 = (temp>>16) - 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
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
