Re: Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
On Tue, 2005-03-22 at 00:56, Detlef wrote: > > 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. If you take out the code that checks to see if they are the same then it might work... > > 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? It the short term probably not, I was curious as I understand that Debian will be moving to X.org for etch and X.org is starting to develop some interesting features and (I'm told) tidy their code base. 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 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: > largest cursor:1280x1024 > red, green, blue masks:0xff, 0xff00, 0xff > Creator 3D > largest cursor:64x64 > 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.
>> 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.
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.
>> 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.
> 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 As I understand it, this converts the output back to the 'old style'. > 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. That may be because it doesn't need to scan the PCI bus in single head mode. Don't know enough about XFree86 to comment. > Section "Device" > Identifier "Creator3D" > Driver "sunffb" > BusID "SBUS:/SUNW,[EMAIL PROTECTED],0" > Option "UseFBDev" "true" > Option "FBDev" "/dev/fb0" > EndSection I don't have the hardware so I can't say if this is a valid BusID but it seems a little sus to me. I could be wrong. > 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. 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. 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.
> > 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. That would be great, I was going to volunteer to try to kludge it but without knowledge of X or hardware with multiple PCI controllers I'll leave it to you, unless, ofcourse anyone /really/ wants me to do it... 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.
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.
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]
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 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.
> >> 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 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.
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.
> 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.
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- SERR- 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- SERR- 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- SERR- 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- SERR- 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- SERR- 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- SERR- 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- SERR- Latency: 64 (2000ns min, 2000ns max), Cache Line Size: 0x10 (64 > bytes) Int
Problems with Xinerama using a Matrox Millenium / Creator 3D with an Ultra 30.
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-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- {mm,active_mm}->context = 051d
tsk->{mm,active_mm}->pgd = f80072cdc000
\|/ \|/
"@'/ .. \`@"
/_| \__/ |_\
\__U_/
modprobe(2666): Oops [#1]
TSTATE: 11009607 TPC: 020f7fe8 TNPC: 020f7fec Y:
Not tainted
TPC:
g0: 006bf400 g1: 0003 g2: 1fde g3:
1fdf
g4: f80070643680 g5: 0200 g6: f80071afc000 g7:
01ff80014000
o0: o1: 0010 o2: 0040 o3:
df000100
o4: 020eab40 o5: 020ea800 sp: f80071afebc1 ret_pc:
020ea800
RPC: <__ksymtab_matroxfb_read_pins+0xa68/0xfda8 [matroxfb_misc]>
l0: f80070a33800 l1: 020eab40 l2: 020eb678 l3:
020fc5ac
l4: l5: l6: 006a3648 l7:
1410
i0: i1: 020eb4f8 i2: 0080 i3:
01ff8080
i4: 005fcfd0 i5: 020eab40 i6: f80071afeca1 i7:
020f8670
I7:
Instruction DUMP: 0b008000 8530a000 8610e3df 8730e000 80a68005
ce5f69d0 0304 39000400
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
