> > The SB1500 will definitely not function right now > > (pci-bridge not supported by sparcPci.c). > > > > Does the SB2500 have the same issue?
Yes. So do the U25 and U45 and also T1000/T2000. A Blade 1000/2000, however, *is* known to work with the current Xorg's sparcPci.c (SPARC32PLUS build Xorg - only). *All* pre-Blade1000/2000 Ultra workstations will also work(Schizo, Psycho, Hummingbird and so on). There are two potential solutions on the horizon: #A) Sun should release enough specs allowing anyone to enhance the current pci scanning frame work (here mostly sparcPci.c) to the missing pci bridges (such as found in most newer systems [now on cpu-dies for a while]). Sun could also hire someone to do that port internally, behind their firewalls, if really necessary. #B) An alternate approach would be, to forget about Xorg's current pci scanning on SPARC's, but rather to switch it to Xsun's bus scanning (that is not performed by Xsun itself (in fact encapsulated and hidden to the Xsun server), but by the /dev/fb kernel drivers and the corresponding ddx modules in /usr/openwin jointly together). To figure out, how to make the data provided by /dev/fb accessible to - and usable by - Xorg would do the trick. I mean, OpenBoot is already aware of the frame buffer(s) that may happen to be present in a given scenario. OpenBoot maintains a corresponding device node for each recognized frame buffer, even if not "supported" by that box (i.e. if you plug a XVR-1000 into an Ultra30). Therefore the kernel mode /dev/fb drivers can find the matching devices (they couldn't without OpenBoot's help, you see that if you plud any UPA card into a SF280R or Netra20, which will not work [unless you convert them into a plain Blade 1000 by removing the RSC / ALOM2&&SCR]). Okay, we have OpenBoot's support, we have redistributable /dev/fb drivers for all graphics cards. And we have one problem: The user mode Xsun ddx modules can never be used inside Xorg, because they are linked against 2^1024 myriads of unresolved Xsun privates. And a wrapper module doesn't make much sense, as it would require to put 90% of Xsun into a dlopen() loadable library, which is impossible for license and security reasons, and would not bring a single performance benefit over stock Xsun, rather the opposite. So the question is, how to make /dev/fb's knowledge and functions usable to Xorg. It should be doable. A good jump into 2008 to anyone on this list! --Martin Bochnig This message posted from opensolaris.org
