On Fri, Feb 13, 2009 at 4:09 PM, John Martin <[email protected]> wrote: > Martin Bochnig wrote: >> >> On Fri, Feb 13, 2009 at 3:55 PM, John Martin <[email protected]> >> wrote: >> >>> >>> Martin Bochnig wrote: >>> >>>> >>>> Are there any chances of seeing pfb or m64 /dev/fb drivers being >>>> published? >>>> >>> >>> This would require permission from AMD/ATI since the code was written >>> using docs under NDA from ATI. >>> >> >> >> Ok, then I cannot expect it to see how the libpciaccess performance >> can be increased on those SPARC bridges where it takes so long. >> Did somebody already talk to the kernel specialists? >> >> > > I wasn't aware there were any pfb or m64 drivers that used libpciaccess. > The drivers, at least as originally written, have their own kernel character > drivers > that handle all the device plumbing requests from the user space X drivers. > > Refresh my memory, what problem needs to be solved?
No, that's exactly it. Somebody who has the /dev/fb kernel driver sources for a /dev/fb driver such as pfb (which would be for the XVR-100 aka Radeon 7000) is able to write a ddx module for Xorg that - in the end - would make it possible to live without aperture/xsvc (by doing all mmap()'ings device-specific, for which you need specific knowledge about register offsets). ALSO: Someone who has those sources can link that kernel driver against Xorg, after having removed all obsolete Xsun symbols. At the end could you call the corresponding init function of that /dev/fb driver, which would initialize the frame buffer after InitOutput() during the server initialization. This is the only way I see, how they (SPARC-gfx group in combination with X11-group) can be able to bypass (disable) libpciaccess's bus scanning (such as what Alan Coopersmith has put in place and described: By not calling xf86BusProbe(); during Server initialization on SPARC inhw/xfree86/common/xf86Init.c). For further information have a look at the Solaris 2.6 X11R6 DDK, specifically at how the cgsix /dev/fb kernel driver and the cg6 Xsun ddx module interact. This interaction had made it possible to leave the Xsun server tree without any user mode bus scanning knowledge (in sharp contrast to all Xorg versions prior to server 1.5 / Xorg 7.4, as well as with all XFree86 versions developed after 1998). And as Alan Coopersmith now suggests that they can afford to disable libpciaccess based pci-scanning on SPARC, I assume they have cloned the old model of /dev/fb vs. Xsun ddx module interaction to work with their new self-developed Xorg ddx modules. I cannot verify this assumptions (closed src), but the known things (http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/xserver/xorg/sparc-nopciprobe.patch and Alan's remarks and also the autoconfigure approach of simply taking what visgetidentifier() reports for a given /dev/fb in http://src.opensolaris.org/source/xref/fox/fox-gate/XW_NV/open-src/xserver/xorg/driver-autoconfig.patch ) hardly leaves any other assumption, than that. Alan Coopersmith's mail I had been referring to was here (same thread) : http://www.opensolaris.org/jive/thread.jspa?threadID=90306&tstart=0 where he stated: """ alanc Posts: 4,332 From: Menlo Park, California Registered: 3/9/05 [xwin-discuss] pciaccess status (was: fox gates & Xorg 1.5/1.6: logical shift left) Posted: Feb 3, 2009 4:00 AM in response to: martinb Click to reply to this thread Reply Martin Bochnig wrote: > I'm also interested to see, how libpciaccess now detects the > corresponding pci bus for each different SPARC platform. That reminds me I should probably report the current state of libpciaccess - with what's integrated into Nevada you should be able to scanpci and see all the devices on both SPARC & x86. However: - on SPARC, Xorg skips the PCI bus scan unless you rebuild without xserver/xorg/sparc-nopciprobe.patch which unconditionally disables it. Having it enabled was causing Xorg to take multiple minutes to start on several SPARC platforms, far longer than gdm/dtlogin are willing to wait for it. Since all the SPARC devices supported in SXCE or 2009.xx will have /dev/fb drivers, PCI bus probing isn't needed for them, so it was disabled. Someone building a distro that wanted to support graphics cards without kernel fb drivers would need this though. We continue to discuss with the kernel teams how to improve the PCITOOL ioctls & devinfo library that libpciaccess uses to get this information to improve the performance to reasonable levels. - on x86, depending on your kernel version, Xorg may see devices that aren't really there, which causes autoconfiguration to fail due to Xorg not knowing which to use as the primary video device. You can work around this by making an xorg.conf that has the bus id specified. Right now, the versions we know work and don't: - up through nv_105: may report too many devices - nv_106 - nv_107: should work on most systems, since we limit the bus ids scanned to bus_range, which due to bug 6782932/6798926 was a small range that on most machines includes the actual devices but not the addresses we previously hit that caused incorrect memory locations to be used in the probes - recent nightlies: the fix for 6798926 returned the bus_range size to the larger values, causing us to We've been working with the kernel PCI guys to get this fixed before ON builds their nv_108 -- they believe the long term fix looks a lot like the one Jürgen Keil suggested in: http://defect.opensolaris.org/bz/show_bug.cgi?id=6100 but may end up backing out 6798926 for nv_108 as the short term fix until the better one can be reviewed, tested & integrated. -- -Alan Coopersmith- alan dot coopersmith at sun dot com Sun Microsystems, Inc. - X Window System Engineering """ _______________________________________________ driver-discuss mailing list [email protected] http://mail.opensolaris.org/mailman/listinfo/driver-discuss
