[Setting Cc to just the dri-devel list; this doesnt seem appropriate to the utah-glx list. (particularly since I'm the only solaris developer on it ;-)] [Note also that I'm not subscribed to dri-devel, though]
On Mon, Apr 15, 2002 at 09:44:39PM -0600, Jens Owen wrote: > Philip Brown wrote: > > nice to hear. What did you have in mind when you say > > "broaden our infrastructure" ? > .. > That said, when I understand where and how the current infrastructure is > limiting your ability to support Solaris, I'm willing to work on the > infrastructure and resulting Linux changes required to keep a single > code base working on multiple OS's. In the end, the extra work will be > less than maintaining two separate infrastructures. > > So, let me turn the question around. What is it you need from the > current DRI/DRM infrastructure that you are not getting today? Okay, long email, in two section: "Solaris limitations", and "ease-of-porting issues". Neither of which strictly require changes to the drm API, but most of which require changes to underlying code. ----- SOLARIS LIMITATIONS -------------- Well, the biggie is that you cannot bind a custom driver to the video card: there is already a solaris video driver, and it has no exported bit-twiddle interfaces for other drivers. So, no using video card interrupts, and no tweaking the registers from driver level. (I think. There might be a way to do register twiddles, but I dont know how to do it.) The good news is that /dev/xsvc still works for register fiddling. So you can take the IO register mapping that the Xserver does, and use the mmaped regs at user level still. You CAN (in theory) use /dev/agpgart, seeing as how it is a separate device that solaris does not normally bind to. I wrote a theoretical solaris version of the agpgart API, that is actually (in theory) completed. But I have had no working graphics progs to test it at this point. It would be best to get something working without AGP support, and then cautiously see how badly things blow up once you turn it on. ----- EASE OF PORTING issues -------------- I think there are some card drivers under dri that "require" agp to work. This has got to be fixed. For every card, there should be a "fall back to using on-board video memory" mode. Similarly, a "fall back to no DMA" mode. Similarly, I believe that there is a check for custom card-specific kenel-level extensions, and if they are not there, DRI does not install itself for that card. That needs to be optional, not a drop-dead issue. Then of course there's the nasty bsd linking hack that I mentioned. If code is shared between OSs, it belongs in the 'shared' directory. Both so that porters know they probably want to use the code, and also that people working on it for existing platforms are aware that they cannot make some funky os-specific tweak in the code. > ... I got > the impression from your previous e-mails that you were looking for a > solution that did not require kernel level support. If security and > multiple direct rendering contexts are not a concern, and won't ever be > for Solaris; then we should talk about taking Utah-GLX like shortcuts > under the DRI. That would be good enough for me. Long-term, maybe others would be interested in fleshing out the other bits, but its not something I care to tackle. Heck, I dont technically even care about "direct" rendering. I'm perfectly happy to go through Xserver communication pipes, and thus solve the "security" issues by letting the Xserver handle it. I can play quake2 just fine with indirect rendering on my old TNT card and Utah-GLX. Contrariwise... maybe use /dev/xsvc "directly", for direct mapping. Solaris has /etc/logindevperm that can be tweaked to automatically adjust ownership of /dev/xsvc to the person logged in on console. Perhaps that is the best way to go. Anyways.... if the aforementioned limitations and needs were accomodated (for Matrox G400 suport, initally, anyways, since thats the card I have now), then I would be interested in looking at taking on the solaris port again. _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
