[Dri-devel] Radeon 8500, XFree86 CVS vs DRI..
Is there any reason why the DRI tree isn't tracking the XFree86 CVS tree more? On my Radeon 8500, the DRI tree apparently still doesn't do the Xv extension correctly, even though XFree86 CVS has done it for ages (thanks to Keith for getting the relevant bits off Gatos). So I have to have two different X servers, depending on whether I want to watch DVD's or whether I want to check 3D behaviour. (The XFree86 CVS tree also has that funky red-cursor-with-a-shadow thing, which I've not yet decided if I like or dis-like ;) Linus --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
AW: [Dri-devel] matrox parhelia vs. opensource?
Title: AW: [Dri-devel] matrox parhelia vs. opensource? A'rpi, besides from the open/closed source issue, what are your experiences with the closed source driver in regard to 3d. Johannes -Ursprüngliche Nachricht- Von: Arpi [mailto:[EMAIL PROTECTED]] Gesendet: Mittwoch, 18. September 2002 22:50 An: [EMAIL PROTECTED] Betreff: [Dri-devel] matrox parhelia vs. opensource? Hi, Quoting matrox's press release about the just released linux driver: http://matrox.com/mga/media_center/press_rel/2002/linux_matrox.cfm Matrox continues to support the Linux community and is proud to release an open source driver for its flagship product Parhelia, providing a modularized driver to satisfy the varied requirements of the Linux community. Matrox's hybrid approach offers an open source module for basic single screen 2D support, and a closed source module offering extended support. I've downloaded the driver tarball (the only downloadable file from their linux driver dload section) - it contains binary only DRI(?) modeles for XF 4.1.0 and 4.2.0, and the source code for the kernel driver only.
Re: [Dri-devel] Radeon 8500, XFree86 CVS vs DRI..
On Wed, Sep 18, 2002 at 11:42:35PM -0700, Linus Torvalds wrote: Is there any reason why the DRI tree isn't tracking the XFree86 CVS tree more? On my Radeon 8500, the DRI tree apparently still doesn't do the Xv extension correctly, even though XFree86 CVS has done it for ages (thanks to Keith for getting the relevant bits off Gatos). So I have to have two different X servers, depending on whether I want to watch DVD's or whether I want to check 3D behaviour. (The XFree86 CVS tree also has that funky red-cursor-with-a-shadow thing, which I've not yet decided if I like or dis-like ;) Because, as i understand it, the developpment cycle of Xfree/DRI is as follows : o XFree does a new release. o At this point DRI and Xfree are in sync, so DRI development is done in the DRI CVS, based on the lastly released XFree tree. o XFree developpment is done in the XFree CVS. o Sometimes near the end of the XFree development cycle, the two trees are synced by hand once the sync is done in a satisfactory way, o XFree does a new release, and all begins again. I think one of the reasons this is so is because the DRI tree is not complete, and needs XFree to build and work correctly, and it is easier for people building from DRI CVS to have the 4.2.0 tarball installed, and build from that. I guess people will try to merge usefull fixes from the XFree tree to the DRI tree if they feel they need them or so, thus making things easier for the folk doing the final sync. Friendly, Sven Luther --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: AW: [Dri-devel] matrox parhelia vs. opensource?
Hi, besides from the open/closed source issue, what are your experiences with the closed source driver in regard to 3d. I have no such card - so i have no experiences at all. Anyway, there is no 3D support in the closed source driver, according to their release notes. It only provides 2d support, for all teh 3 displays. And, some search inside the binary shown me that there is probably no Xvideo support at all. I'm interested in it, as I'm the main developer of mga_vid, a high speed/quality video overlay driver for matrox g200..g550 cards (used by most linux video players), and wonder if i will be able to support parhelia at all, if no specs and opensource drivers available. A'rpi / Astral ESP-team -- Developer of MPlayer, the Movie Player for Linux - http://www.MPlayerHQ.hu --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, XFree86 CVS vs DRI..
Sven LUTHER wrote: On Wed, Sep 18, 2002 at 11:42:35PM -0700, Linus Torvalds wrote: Is there any reason why the DRI tree isn't tracking the XFree86 CVS tree more? Linus, Think of the DRI trunk as a 3D development branch of XFree86. For the 8500, we've been focused on developing the 3D driver with full TCL support. Other non-3D enhancements have been happening in the main branch (XFree86). The 3D enhancements will be merged into the main development branch of XFree86 before 4.3 goes out. On my Radeon 8500, the DRI tree apparently still doesn't do the Xv extension correctly, even though XFree86 CVS has done it for ages (thanks to Keith for getting the relevant bits off Gatos). So I have to have two different X servers, depending on whether I want to watch DVD's or whether I want to check 3D behaviour. A word of caution about DRM compatability and Gatos. I'm not certain how much of the Gatos functionality Keith P. has integrated into XFree86, but they have been releasing DRM drivers that are not backwards compatible with old XFree86 releases. My understanding of the problem is the Gatos guys need a modified DRM memory map layout and have not been focused on the compatability issue. I'm confident this issue could be resolved if someone interested (and capable) of understanding the Gatos modifications and the DRI backward compatability issues were to dig into this issue. However, to date, nobody has successfully addressed this issue. (The XFree86 CVS tree also has that funky red-cursor-with-a-shadow thing, which I've not yet decided if I like or dis-like ;) Because, as i understand it, the developpment cycle of Xfree/DRI is as follows : o XFree does a new release. o At this point DRI and Xfree are in sync, so DRI development is done in the DRI CVS, based on the lastly released XFree tree. o XFree developpment is done in the XFree CVS. o Sometimes near the end of the XFree development cycle, the two trees are synced by hand once the sync is done in a satisfactory way, The syncing can and has actually happened more frequently than once per release. o XFree does a new release, and all begins again. I think one of the reasons this is so is because the DRI tree is not complete, and needs XFree to build and work correctly, and it is easier for people building from DRI CVS to have the 4.2.0 tarball installed, and build from that. I guess people will try to merge usefull fixes from the XFree tree to the DRI tree if they feel they need them or so, thus making things easier for the folk doing the final sync. Friendly, Sven Luther --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, XFree86 CVS vs DRI..
Around 9 o'clock on Sep 19, Jens Owen wrote: A word of caution about DRM compatability and Gatos. I'm not certain how much of the Gatos functionality Keith P. has integrated into XFree86, but they have been releasing DRM drivers that are not backwards compatible with old XFree86 releases. I haven't really integrated any of the Gatos code into XFree86. I worked with Kevin Martin to get all of the Radeon chips doing YUV overlays, but that took register settings from the Gatos code along with some additional fixes. The Gatos project code supports significantly more video functionality, but remains somewhat limited in other dimensions, such as card support and video mode selection. Kevin has also been busy integrating 2D code from ATI for the Radeon chips into the XFree86 tree. That's certainly helping a lot of people; I can finally safely restart my X server. The large number of different Radeon chips has made universal support for all features very difficult; few developers have access to all of the variations, especially the laptop versions. My understanding is that ATI does make developer AGP boards with laptop chips; it seems like it might be useful to try and get some of those for the DRI developers to do a bit more testing. The other dimension of variation is that we have three separate groups working on various ATI features; XFree86 does 2D graphics, Gatos does video and DRI does 3D graphics. I don't see how we can expect each team to track the other two on an ongoing basis; merging source pools takes time away from other more interesting development. (The XFree86 CVS tree also has that funky red-cursor-with-a-shadow thing, which I've not yet decided if I like or dis-like ;) Yeah, it's a pretty lame effort at a consistent cursor theme. I haven't every been known for my graphic artistry. Of course, additional sample cursor themes would be really nice to have. Keith PackardXFree86 Core TeamHP Cambridge Research Lab --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Radeon 8500, XFree86 CVS vs DRI..
On Thu, 19 Sep 2002, Linus Torvalds wrote: ( Yes, the Gatos people do not share some of the same concerns the XFree86 people do. I know XFree86 people must sometimes be frustrated with the fast-and-lose just get it working approach of some of the Gatos code, but I bet that the Gatos people are frustrated about the fact that sometimes the XFree86 people don't seem to care about some things _working_ at all. Stability of a code-base that doesn't do what people need it to do is simply not very relevant sometimes. ) I feel that I should point out that functionality of a code-base that isn't stable is simply not very relevant sometimes, too. :-) Adam --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Debugging DRM kernel modules
Hi, What is the preferred debugging method used for debugging loadable DRM kernel modules? Has anyone successfully used kgdb for debugging their driver? Any insight into this would be appreciated. Please CC me as I'm not subscribed to the list yet. Thanks, -- Bhavana Nagendra --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Debugging DRM kernel modules
Bhavana Nagendra wrote: Hi, What is the preferred debugging method used for debugging loadable DRM kernel modules? Has anyone successfully used kgdb for debugging their driver? Any insight into this would be appreciated. I believe kprintf is the usual method. Please CC me as I'm not subscribed to the list yet. I would encourage you to subscribe if you're going to be supporting any DRM or other DRI components. These interfaces do evolve and this is the forum where they are reviewed and discussed. Regards, Jens -- /\ Jens Owen/ \/\ _ [EMAIL PROTECTED] /\ \ \ Steamboat Springs, Colorado --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
