Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On Mon, 2005-03-21 at 01:18, Detlef wrote: I dug a bit deeper and xdpyinfo shows a slight difference between the visuals regarding the RGB masks and the largest cursor (see the partly cut output of xdpyinfo below). I suspect the RGB masks the reason for the screens being incompatible and have posted this to the X-Newsgroups but haven't received any answer (yet). Matrox: snip largest cursor:1280x1024 snip red, green, blue masks:0xff, 0xff00, 0xff snip Creator 3D snip largest cursor:64x64 snip red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits At a guess I'd say the cursor issues are solveable but that the colour map ones aren't, without a lot of hacking - or perhaps being red/green colourblind. It's good to know it works, esp. that you can get X running on a Sun box with a non Sun graphics card - very encouraging. The only writeoff is that no real acceleration is used, neither on the the Creator 3d nor on the Millenium. Unless you are planning lots of 3D or video work I wouldn't have thought it was a major issue. In addition the Creator likes only working in 24bit mode although xpdyinfo reports all other depths as well. Other than that it works now fine in double head mode (without Xinerama). Cool. Now I run it deliberately in 24bit on the Creator and 16 Bit on the Matrox, which makes the Matrox slightly faster, but still not as fast as the C-3D. I wonder if the Matrox driver could come with the next debian Kernel as a module. Ideally it would be useful to have all of the FB drivers built as (at least) modules as I suspect this approach may work with other PCI graphics cards. Have you attempted the same set up with X.org? Cheers, - Martin -- Martin [EMAIL PROTECTED] Seasons change, things come to pass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
At a guess I'd say the cursor issues are solveable but that the colour map ones aren't, without a lot of hacking - or perhaps being red/green colourblind. :-). Maybe i can get it to work in inverse. Unless you are planning lots of 3D or video work I wouldn't have thought it was a major issue. Not planning to do any 3D work with it. Is a bit slow though, but I'd wish Graphics was faster. (I started overclocking it a bit, currently it seems running happily wit 300Mhz (250Mhz Processor)), have not tried anything faster than that yet. I'd wish PCs were as easy as that for overclocking. I wonder if the Matrox driver could come with the next debian Kernel as a module. Ideally it would be useful to have all of the FB drivers built as (at least) modules as I suspect this approach may work with other PCI graphics cards. Could work. Probably worth a test. Have you attempted the same set up with X.org? Nope, not yet. Don't dare to at the moment. Could spoil a day or two. I had a bit of a read around and I did not get the feeling that Xorg will be an advantage, will it? Cheers, - Martin -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On Fri, 2005-03-18 at 07:50, Detlef wrote: Section Device Identifier Matrox Millenium Driver fbdev BusID 0001:00:02.0 Option UseFBDev true Option FBDev /dev/fb1 EndSection Isn't this still a 'new style' address, the things you aren't producing any more. Might this be (a|the) problem. Right, changed it back to the old stsle address, got a xinerama error switched this off and now it works fine in double head mode but without xinerama. Cool. Might the error be that you have the screens set up with different colour depths? IIRC Xinerama doesn't like that. The XFConfig-4 is attached. Didn't appear to be. As well I had to comment out the horizontal sync rate from the Monitor section. With this in, the screen was kinda garbled and pinkish. Dunno why. Hmmm... strange - have to tried running xvidtune to see what it's running at now. Finally I used only two hacks, The one to the sparc64/Kconfig file, and reverting back to the old pci structure in /proc, and magic it nearly works. Xinerama is probably off topic for this group but I will continue on this. Double head is sufficient for now. It's good to know it works, esp. that you can get X running on a Sun box with a non Sun graphics card - very encouraging. Cheers, - Martin -- Martin [EMAIL PROTECTED] Seasons change, things come to pass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
Right, changed it back to the old stsle address, got a xinerama error switched this off and now it works fine in double head mode but without xinerama. Cool. Might the error be that you have the screens set up with different colour depths? IIRC Xinerama doesn't like that. Nope, both were setup using 1280x1024x24. I dug a bit deeper and xdpyinfo shows a slight difference between the visuals regarding the RGB masks and the largest cursor (see the partly cut output of xdpyinfo below). I suspect the RGB masks the reason for the screens being incompatible and have posted this to the X-Newsgroups but haven't received any answer (yet). Matrox: dimensions:1280x1024 pixels (325x260 millimeters) resolution:100x100 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x52 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:1280x1024 current input event mask:0xfa2033 KeyPressMask KeyReleaseMask EnterWindowMask LeaveWindowMask ButtonMotionMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:4 default visual id: 0x22 visual: visual id:0x22 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits Creator 3D dimensions:1280x1024 pixels (325x260 millimeters) resolution:100x100 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x54 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x38 default number of colormap cells:256 preallocated pixels:black 0, white 16711422 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xfa2033 KeyPressMask KeyReleaseMask EnterWindowMask LeaveWindowMask ButtonMotionMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:4 default visual id: 0x3a visual: visual id:0x3a class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits It's good to know it works, esp. that you can get X running on a Sun box with a non Sun graphics card - very encouraging. The only writeoff is that no real acceleration is used, neither on the the Creator 3d nor on the Millenium. In addition the Creator likes only working in 24bit mode although xpdyinfo reports all other depths as well. Other than that it works now fine in double head mode (without Xinerama). Now I run it deliberately in 24bit on the Creator and 16 Bit on the Matrox, which makes the Matrox slightly faster, but still not as fast as the C-3D. I wonder if the Matrox driver could come with the next debian Kernel as a module. cheers Detlef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
Section Device Identifier Matrox Millenium Driver fbdev BusID 0001:00:02.0 Option UseFBDev true Option FBDev /dev/fb1 EndSection Isn't this still a 'new style' address, the things you aren't producing any more. Might this be (a|the) problem. Right, changed it back to the old stsle address, got a xinerama error switched this off and now it works fine in double head mode but without xinerama. The XFConfig-4 is attached. As well I had to comment out the horizontal sync rate from the Monitor section. With this in, the screen was kinda garbled and pinkish. Dunno why. Finally I used only two hacks, The one to the sparc64/Kconfig file, and reverting back to the old pci structure in /proc, and magic it nearly works. Xinerama is probably off topic for this group but I will continue on this. Double head is sufficient for now. Slightly more tangentially, have you tried on a 2.4 series kernel or tried X.org? That might give you some intuition into whether it's possible and what other problems there might be. Nope, It takes an hour to build a Kernel on an Ultra 30, sometimes more. I just used 2.6. Now I'm only left with a weird mouse problem I will post this separately cheers thanks for all your help Detlef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
David S. Miller wrote: On 16 Mar 2005 02:48:27 + Martin [EMAIL PROTECTED] wrote: This: http://lists.debian.org/debian-sparc/2004/05/msg00203.html purports to be a patch, seems a bit hack-ish but looks like a start. I guess it's not a complete solution for the reason given here: http://lists.debian.org/debian-sparc/2004/01/msg00026.html Right, it only works when your video card is behind the first PCI controller. The latest CVS version of XFree86 seems to have a different solution which I /think/ solves the problem. http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c change 249 249. Deal with Linux 2.6's PCI bus naming (Marc La France). It looks promising. But given that 4.4 won't be in Debian for licencing reasons and there is a migration to X.org planned for post-sarge it does seem like quite a reasonable approach to solving the problem. Right, and I'm more than happy to work on a careful backport of that patch. I'll try to find some time for that. Thanks for this, I havnet had much time today but I implemented the hack as laid out in http://lists.debian.org/debian-sparc/2004/02/msg00013.html Now lspci and scanpci do indeed show the same output again. XFree86 -scanpci is still empty and X does not start in multihead mode: Fatal server error: Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices But I specified them in the XF86Config-4 and each card is working fine in a single screen layout with the data below. Section Device Identifier Creator3D Driver sunffb BusID SBUS:/SUNW,[EMAIL PROTECTED],0 Option UseFBDev true Option FBDev /dev/fb0 EndSection Section Device Identifier Matrox Millenium Driver fbdev BusID 0001:00:02.0 Option UseFBDev true Option FBDev /dev/fb1 EndSection -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
Hi All, I feel a bit silly, and had the PCI Bus ID specified in the wrong way. Done it right now and the MGA FBDEV works without probs. But although I have specified both BusID in my XF86Config-4, X is still trying to tell me I need to specify both Bus IDs. Is a multihead / Xinerama configuration with Sparc possible at all? regards thanks for any Ideas you might have. Detlef Hi out there, Got my Ultra Sparc 30 installed with Debian Sarge and fixed the usual Keyboard problems. I then compiled an own Kernel 2.6.11.2 to have support for the additional Adaptec SCSI Controller and Matrox Graphics card. Both seem to work well. For the Matrox I use the Framebuffer device that comes with the 2.6 Kernels. BUT the Matrox framebuffer will only work when no BusID is specified in the Device Section, otherwise I get an illegal paging request, as laid out below. Driver MGA does not work as X does not see the card. If I add the Creator 3D X seems to require BusID's specified with every device. I suspect there is something wrong with the PCI scan of X. Scanpci does only list the 66MHz PCI Bus omitting the second bus installed whereas lspci sees all of the devices. I wondered if anyone could help me with this. The lspci/scanpci output, Error reported as soon as I add the BusID in the Device section and my XFConfig file are below. regards Detlef ## LSPCI -VV ## :80:00.0 Host bridge: Sun Microsystems Computer Corp. Psycho PCI Bus Module 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: 64 0001:00:00.0 Host bridge: Sun Microsystems Computer Corp. Psycho PCI Bus Module 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: 64 0001:00:01.0 Bridge: Sun Microsystems Computer Corp. EBUS (rev 01) 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: 80 (2500ns min, 6250ns max), Cache Line Size: 0x10 (64 bytes) Region 0: Memory at 01fff000 (32-bit, non-prefetchable) [size=16M] Region 1: Memory at 01fff100 (32-bit, non-prefetchable) [size=8M] Expansion ROM at 8200 [disabled] [size=16M] 0001:00:01.1 Ethernet controller: Sun Microsystems Computer Corp. Happy Meal (rev 01) 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: 80 (2500ns min, 1250ns max), Cache Line Size: 0x10 (64 bytes) Interrupt: pin ? routed to IRQ 7428576 Region 0: Memory at 01ff80008000 (32-bit, non-prefetchable) [size=32K] Expansion ROM at 8300 [disabled] [size=16M] 0001:00:02.0 VGA compatible controller: Matrox Graphics, Inc. MGA 2064W [Millennium] (rev 01) (prog-if 00 [VGA]) 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- Interrupt: pin A routed to IRQ 7428032 Region 0: Memory at 01ff80014000 (32-bit, non-prefetchable) [size=16K] Region 1: Memory at 01ff8080 (32-bit, prefetchable) [size=8M] Expansion ROM at 8002 [disabled] [size=64K] 0001:00:03.0 SCSI storage controller: LSI Logic / Symbios Logic 53c875 (rev 03) 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: 136 (4250ns min, 16000ns max), Cache Line Size: 0x10 (64 bytes) Interrupt: pin A routed to IRQ 7428544 Region 0: I/O ports at 2010400 [size=256] Region 1: Memory at 01ff8001 (32-bit, non-prefetchable) [size=256] Region 2: Memory at 01ff80011000 (32-bit, non-prefetchable) [size=4K] 0001:00:05.0 SCSI storage controller: Adaptec AHA-2940/2940W / AIC-7871 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: 64 (2000ns
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
Got my Ultra Sparc 30 installed with Debian Sarge and fixed the usual Keyboard problems. I then compiled an own Kernel 2.6.11.2 to have support for the additional Adaptec SCSI Controller and Matrox Graphics card. Both seem to work well. For the Matrox I use the Framebuffer device that comes with the 2.6 Kernels. Fnar! I've been meaning to try that for ages. Ran out of time after finding that PC ATi Rage cards kill the firmware on Ultra AXi boards. Oh well - good to know it works. Have you tried it with any other PCI cards? Also are you using the card with the 'be a VGA card' DIP switch set? BUT the Matrox framebuffer will only work when no BusID is specified in the Device Section, otherwise I get an illegal paging request, as laid out below. Driver MGA does not work as X does not see the card. I'm not sure it has been 'officially ported' or not. The stable xfree86-server package doesn't have it and (IIRC) it wasn't listed as supported on Linux/SPARC last time I looked. It's possible that it been set to build but never actually tested. If I add the Creator 3D X seems to require BusID's specified with every device. Have you tried with two matrox millenium cards? Might be a problem with the particular combination of drivers? I suspect there is something wrong with the PCI scan of X. Scanpci does only list the 66MHz PCI Bus omitting the second bus installed whereas lspci sees all of the devices. There certainly used to be something wrong with it. Check the archives for around autumn last year (IIRC), there was a patch for handling scanning the PCI bus. As regards whether multi-head is possible or not. People have posted to the list claiming to have working set ups in the past and I see know reason why it /shouldn't/ work. Attempting this properly is slowly climbing up my list of priorities. HTH Cheers, - Martin -- Martin [EMAIL PROTECTED] Seasons change, things come to pass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
Martin wrote: Got my Ultra Sparc 30 installed with Debian Sarge and fixed the usual Keyboard problems. I then compiled an own Kernel 2.6.11.2 to have support for the additional Adaptec SCSI Controller and Matrox Graphics card. Both seem to work well. For the Matrox I use the Framebuffer device that comes with the 2.6 Kernels. Fnar! I've been meaning to try that for ages. Ran out of time after finding that PC ATi Rage cards kill the firmware on Ultra AXi boards. Oh well - good to know it works. Have you tried it with any other PCI cards? Also are you using the card with the 'be a VGA card' DIP switch set? Nope, have just tried the adaptec and matrox millenium I (dunno if its got dipsies, dint have to change any though ;-). 24bit Video modes are a bit odd, the left 1/8th of the screen is on the right hand side. but 8 and 16 seem to work fine so far. BUT the Matrox framebuffer will only work when no BusID is specified in the Device Section, otherwise I get an illegal paging request, as laid out below. Driver MGA does not work as X does not see the card. I'm not sure it has been 'officially ported' or not. The stable xfree86-server package doesn't have it and (IIRC) it wasn't listed as supported on Linux/SPARC last time I looked. It's possible that it been set to build but never actually tested. probably so, the module mga is included but doesnt work. If I add the Creator 3D X seems to require BusID's specified with every device. Have you tried with two matrox millenium cards? Might be a problem with the particular combination of drivers? Cant do, only have one and the Creator already came with the box. The Xfree log looks OK though (to how far I can understand it). X just moans about necessity to have the BusID specified but I f'ing have! I suspect there is something wrong with the PCI scan of X. Scanpci does only list the 66MHz PCI Bus omitting the second bus installed whereas lspci sees all of the devices. There certainly used to be something wrong with it. Check the archives for around autumn last year (IIRC), there was a patch for handling scanning the PCI bus. I have seen one message about this but was not able to find out more. where and how would I look for these? Would really like to get this fixed. As regards whether multi-head is possible or not. People have posted to the list claiming to have working set ups in the past and I see know reason why it /shouldn't/ work. Attempting this properly is slowly climbing up my list of priorities. It got me some deeper understanding of X though, specially the XFree config file. HTH Cheers, - Martin Cheers Detlef -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On Tue, 15 Mar 2005 21:34:04 +0100 Detlef [EMAIL PROTECTED] wrote: Is a multihead / Xinerama configuration with Sparc possible at all? I've gotten it to work often with multiple creator3d cards, but never with mixed card types. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
Got my Ultra Sparc 30 installed with Debian Sarge and fixed the usual Keyboard problems. I then compiled an own Kernel 2.6.11.2 to have support for the additional Adaptec SCSI Controller and Matrox Graphics card. Both seem to work well. For the Matrox I use the Framebuffer device that comes with the 2.6 Kernels. Fnar! I've been meaning to try that for ages. Ran out of time after finding that PC ATi Rage cards kill the firmware on Ultra AXi boards. Oh well - good to know it works. Have you tried it with any other PCI cards? Also are you using the card with the 'be a VGA card' DIP switch set? Nope, have just tried the adaptec and matrox millenium I (dunno if its got dipsies, dint have to change any though ;-). Some have DIP switches that change it between being a normal VGA graphics card and a secondary adaptor. This only seems to make a difference on x86 systems when it comes to initialising graphics cards and allocation of address ranges. 24bit Video modes are a bit odd, the left 1/8th of the screen is on the right hand side. Bizaar. Have you tried tampering with the modeline? but 8 and 16 seem to work fine so far. Cool! If I add the Creator 3D X seems to require BusID's specified with every device. Have you tried with two matrox millenium cards? Might be a problem with the particular combination of drivers? Cant do, only have one and the Creator already came with the box. I've got a few lying round here so I'll try with multiple matrox cards at some point. The Xfree log looks OK though (to how far I can understand it). X just moans about necessity to have the BusID specified but I f'ing have! Hmmm... bizaar. I would suggest asking the X dev community but I suspect you're more likely to get support out of the X.org lists. Have you considered / tried using X.org? I suspect there is something wrong with the PCI scan of X. Scanpci does only list the 66MHz PCI Bus omitting the second bus installed whereas lspci sees all of the devices. There certainly used to be something wrong with it. Check the archives for around autumn last year (IIRC), there was a patch for handling scanning the PCI bus. I have seen one message about this but was not able to find out more. where and how would I look for these? I think it was relating to running X on SPARC on a 2.6 kernel and was around the time 2.6 came out. Which would mean it was some time in 2004. Download the archives and grep or google seem like your best options. Cheers, - Martin -- Martin [EMAIL PROTECTED] Seasons change, things come to pass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On 16 Mar 2005 01:27:49 + Martin [EMAIL PROTECTED] wrote: I suspect there is something wrong with the PCI scan of X. Scanpci does only list the 66MHz PCI Bus omitting the second bus installed whereas lspci sees all of the devices. There certainly used to be something wrong with it. Check the archives for around autumn last year (IIRC), there was a patch for handling scanning the PCI bus. I have seen one message about this but was not able to find out more. where and how would I look for these? I think it was relating to running X on SPARC on a 2.6 kernel and was around the time 2.6 came out. Which would mean it was some time in 2004. Download the archives and grep or google seem like your best options. The PCI device tree names under /proc/bus/pci have changed to the format of: /proc/bus/pci/$(PCI_DOMAIN_NUM):$(PCI_BUS_NUM)/ instead of the old: /proc/bus/pci/$(PCI_BUS_NUM)/ X's device probe has never been fixed to handle this correctly. It really needs this fix, as X is busted on multiple platforms with 2.6.x kernels because of this. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
I suspect there is something wrong with the PCI scan of X. Scanpci does only list the 66MHz PCI Bus omitting the second bus installed whereas lspci sees all of the devices. There certainly used to be something wrong with it. Check the archives for around autumn last year (IIRC), there was a patch for handling scanning the PCI bus. I have seen one message about this but was not able to find out more. where and how would I look for these? I think it was relating to running X on SPARC on a 2.6 kernel and was around the time 2.6 came out. Which would mean it was some time in 2004. Download the archives and grep or google seem like your best options. The PCI device tree names under /proc/bus/pci have changed to the format of: /proc/bus/pci/$(PCI_DOMAIN_NUM):$(PCI_BUS_NUM)/ instead of the old: /proc/bus/pci/$(PCI_BUS_NUM)/ X's device probe has never been fixed to handle this correctly. It really needs this fix, as X is busted on multiple platforms with 2.6.x kernels because of this. This: http://lists.debian.org/debian-sparc/2004/05/msg00203.html purports to be a patch, seems a bit hack-ish but looks like a start. I guess it's not a complete solution for the reason given here: http://lists.debian.org/debian-sparc/2004/01/msg00026.html The latest CVS version of XFree86 seems to have a different solution which I /think/ solves the problem. http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c change 249 249. Deal with Linux 2.6's PCI bus naming (Marc La France). But given that 4.4 won't be in Debian for licencing reasons and there is a migration to X.org planned for post-sarge it does seem like quite a reasonable approach to solving the problem. HTH Cheers, - Martin For the sake of completeness there are a number of suggested kernel hacks: http://lists.debian.org/debian-sparc/2004/02/msg00013.html http://lists.debian.org/debian-x/2003/12/msg00404.html and a simpiler hack for X (that is listed as 'works in some but not all cases') http://lists.debian.org/debian-sparc/2004/01/msg00027.html and the whole thread kicks off here: http://lists.debian.org/debian-sparc/2003/12/msg00182.html -- Martin [EMAIL PROTECTED] Seasons change, things come to pass -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On 16 Mar 2005 02:48:27 + Martin [EMAIL PROTECTED] wrote: This: http://lists.debian.org/debian-sparc/2004/05/msg00203.html purports to be a patch, seems a bit hack-ish but looks like a start. I guess it's not a complete solution for the reason given here: http://lists.debian.org/debian-sparc/2004/01/msg00026.html Right, it only works when your video card is behind the first PCI controller. The latest CVS version of XFree86 seems to have a different solution which I /think/ solves the problem. http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/bus/linuxPci.c change 249 249. Deal with Linux 2.6's PCI bus naming (Marc La France). It looks promising. But given that 4.4 won't be in Debian for licencing reasons and there is a migration to X.org planned for post-sarge it does seem like quite a reasonable approach to solving the problem. Right, and I'm more than happy to work on a careful backport of that patch. I'll try to find some time for that. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
