Re: DRM kernel source broken/incomplete
On Tue, Mar 22, 2005 at 07:52:28AM +, Thorsten Glaser wrote: Alex Deucher dixit: and two for bsd 1. bsd monolithic 2. bsd-coremodular as above why not just let the kernel provide the drm? Most if not all recent linux and bsd kernels (last few years) have drm support. The dri and ddx will adapt depending on what's available in the kernel. For the record, BSD seems to mean FreeBSD exclusively here (and maybe DragonFly, which relates to FreeBSD like MirOS relates to OpenBSD, namely being a fork). I've tried to build DRI/DRM on OpenBSD and MirOS for XF86 4.4; I eventually got DRI working but it just blanked the screen instead of using Mesa when it didn't find a DRM, which is a K.O. criterium, thus I haven't looked deeper into it. The DRM use FreeBSD-ish bsd.kmod.mk whereas OpenBSD and derivates have bsd.lkm.mk, and from a short glimpse on the code I've got the impression it's non-trivial to support OpenBSD too. I'm not too experienced in kernel programming though. That's pretty much the same conclusion I came to. I think we _can_ load kernel modules though, I've played with a VMware 3 module some time (but VMware didn't want to play with me, so I left). If that screen blank, no Mesa issue is fixed, you could probably enable DRI builds on OpenBSD and MirOS, too. I haven't looked into it on 4.5 yet. It only makes sense if working DRM modules are available though. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
Alex Deucher dixit: and two for bsd 1. bsd monolithic 2. bsd-coremodular as above why not just let the kernel provide the drm? Most if not all recent linux and bsd kernels (last few years) have drm support. The dri and ddx will adapt depending on what's available in the kernel. For the record, BSD seems to mean FreeBSD exclusively here (and maybe DragonFly, which relates to FreeBSD like MirOS relates to OpenBSD, namely being a fork). I've tried to build DRI/DRM on OpenBSD and MirOS for XF86 4.4; I eventually got DRI working but it just blanked the screen instead of using Mesa when it didn't find a DRM, which is a K.O. criterium, thus I haven't looked deeper into it. The DRM use FreeBSD-ish bsd.kmod.mk whereas OpenBSD and derivates have bsd.lkm.mk, and from a short glimpse on the code I've got the impression it's non-trivial to support OpenBSD too. I'm not too experienced in kernel programming though. I think we _can_ load kernel modules though, I've played with a VMware 3 module some time (but VMware didn't want to play with me, so I left). If that screen blank, no Mesa issue is fixed, you could probably enable DRI builds on OpenBSD and MirOS, too. I haven't looked into it on 4.5 yet. bye, //mirabile -- [...] Echtzeit hat weniger mit Speed[...] zu tun, sondern damit, daß der richtige Prozeß voraussagbar rechtzeitig sein Zeitscheibchen bekommt. Wir haben uns[...] geeinigt, dass das verwendete Echtzeit-Betriebssystem[...] weil selbst einfachste Operationen *echt* *Zeit* brauchen. (aus d.a.s.r) ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Wed, Feb 16, 2005 at 06:03:41PM -0500, David Dawes wrote: On Wed, Feb 09, 2005 at 11:55:58AM -0500, David Dawes wrote: On Wed, Feb 09, 2005 at 10:05:38AM +, Alan Hourihane wrote: But isn't it better to move forward than backwards ? If the result is no better, then we need to fix the problems found. Going back to an older version, and just because it builds, doesn't guarantee it's going to work any better either. I've got more faith in the current DRM CVS as people are actively working on it, rather than using an older snapshot that people could be unwilling to go back and fix if a problem was found. I'd like to see a version that is proven to build, work, and fit in with our requirements before making any final decision on this. The snapshot we currently have imported is clearly not a good one. Otherwise, going back to the version of the kernel modules that we shipped with 4.4.0 won't be too difficult, especially if the user-mode side has the level of backward compatibility that people have claimed. Is there any update on this? Since the DRM people are not able to come up with a working version, I'm rolling back to the version that we shipped with 4.4.0 as a base for 4.5.0, and I'll work from there. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Wed, Feb 09, 2005 at 11:55:58AM -0500, David Dawes wrote: On Wed, Feb 09, 2005 at 10:05:38AM +, Alan Hourihane wrote: But isn't it better to move forward than backwards ? If the result is no better, then we need to fix the problems found. Going back to an older version, and just because it builds, doesn't guarantee it's going to work any better either. I've got more faith in the current DRM CVS as people are actively working on it, rather than using an older snapshot that people could be unwilling to go back and fix if a problem was found. I'd like to see a version that is proven to build, work, and fit in with our requirements before making any final decision on this. The snapshot we currently have imported is clearly not a good one. Otherwise, going back to the version of the kernel modules that we shipped with 4.4.0 won't be too difficult, especially if the user-mode side has the level of backward compatibility that people have claimed. Is there any update on this? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 08:14:59PM -0500, David Dawes wrote: Some have said here today that the drivers can adapt to older DRM versions. That's how it should be, but I don't know if it is true or not. I've seen some things in my initial testing that may cast some doubt on it, but there were too many other variables to be certain without followup. Following up on this, if I start XFree86 with DRI enabled with an i810, on Red Hat 9 with its stock kernel and DRM module, the server gets killed by the kernel. The reason is that it tries to open up to 255 minor device nodes (vs 16 before), but some versions of the DRM have a hard limit of 16 and unfortunately don't validate the minor number before using it to index an array. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 08:14:59PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 11:52:27PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:40:07PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. If we import the current DRM trunk code, there are three linux directories. 1. linux for 2.4 kernels (monolithic) 2. linux-2.6 for 2.6 kernels (monolithic) 3. linux-core for 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsdmonolithic 2. bsd-core modular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. At this point in our release cycle, the priorities are: 1st: It builds/runs and is reasonably stable on a good range of platforms. 2nd: It supports as many DRI features as possible consistent with the first priority. I don't think that even changing from the existing single Linux directory to two different kernel-specific directories is appropriate at this point in our release cycle. The time for such a change was before the feature freeze. If what we have now is too broken to be fixed without major structural changes, then it will need to be rolled back. The fear is, if you roll back the DRM, then the drivers may need to be rolled back as well to support lesser features. Some have said here today that the drivers can adapt to older DRM versions. That's how it should be, but I don't know if it is true or not. I've seen some things in my initial testing that may cast some doubt on it, but there were too many other variables to be certain without followup. It would clearly be preferable to have a recent version that works. Is there a known recent stable/working version? From my point of view the fear is, updating to the latest version, adapting to its structural changes, and finding that the result is no better. But isn't it better to move forward than backwards ? If the result is no better, then we need to fix the problems found. Going back to an older version, and just because it builds, doesn't guarantee it's going to work any better either. I've got more faith in the current DRM CVS as people are actively working on it, rather than using an older snapshot that people could be unwilling to go back and fix if a problem was found. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Wed, Feb 09, 2005 at 10:05:38AM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 08:14:59PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 11:52:27PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:40:07PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. If we import the current DRM trunk code, there are three linux directories. 1. linux for 2.4 kernels (monolithic) 2. linux-2.6 for 2.6 kernels (monolithic) 3. linux-corefor 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsd monolithic 2. bsd-core modular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. At this point in our release cycle, the priorities are: 1st: It builds/runs and is reasonably stable on a good range of platforms. 2nd: It supports as many DRI features as possible consistent with the first priority. I don't think that even changing from the existing single Linux directory to two different kernel-specific directories is appropriate at this point in our release cycle. The time for such a change was before the feature freeze. If what we have now is too broken to be fixed without major structural changes, then it will need to be rolled back. The fear is, if you roll back the DRM, then the drivers may need to be rolled back as well to support lesser features. Some have said here today that the drivers can adapt to older DRM versions. That's how it should be, but I don't know if it is true or not. I've seen some things in my initial testing that may cast some doubt on it, but there were too many other variables to be certain without followup. It would clearly be preferable to have a recent version that works. Is there a known recent stable/working version? From my point of view the fear is, updating to the latest version, adapting to its structural changes, and finding that the result is no better. But isn't it better to move forward than backwards ? If the result is no better, then we need to fix the problems found. Going back to an older version, and just because it builds, doesn't guarantee it's going to work any better either. I've got more faith in the current DRM CVS as people are actively working on it, rather than using an older snapshot that people could be unwilling to go back and fix if a problem was found. I'd like to see a version that is proven to build, work, and fit in with our requirements before making any final decision on this. The snapshot we currently have imported is clearly not a good one. Otherwise, going back to the version of the kernel modules that we shipped with 4.4.0 won't be too difficult, especially if the user-mode side has the level of backward compatibility that people have claimed. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
DRM kernel source broken/incomplete
It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? What about the FreeBSD code? The current version we have is very broken, failing to build even the simplest of drivers (tdfx) on 4.10 or 5.2. Also, does the i915 driver build on BSD? It is referenced in the Makefile, but the required files are not present. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. What about the FreeBSD code? The current version we have is very broken, failing to build even the simplest of drivers (tdfx) on 4.10 or 5.2. Also, does the i915 driver build on BSD? It is referenced in the Makefile, but the required files are not present. I've not built the BSD code for quite some time. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tuesday 08 of February 2005 17:59, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? What about the FreeBSD code? The current version we have is very broken, failing to build even the simplest of drivers (tdfx) on 4.10 or 5.2. Also, does the i915 driver build on BSD? It is referenced in the Makefile, but the required files are not present. Just as a note: FreeBSD includes drm in its source since 5.0 release and 4.9 release in src/sys/dev/drm: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/drm/ The current code in FreeBSD CVS is based on 2004-05-26 DRI CVS. AFAIK Intel drivers are not yet supported. Dejan ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, 8 Feb 2005, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? How often does the Xserver / DRM binary interface change - is it viable to just use the DRM in the running kernel ? I suppose this is really a question for one of the DRM lists but, is it a forlorn hope that the DRM could have a static binary interface to either the kernel or the X server ? (I guess that a moving kernel puts the former outside the control of the DRM project ?) -- Dr. Andrew C. Aitchison Computer Officer, DPMMS, Cambridge [EMAIL PROTECTED] http://www.dpmms.cam.ac.uk/~werdna ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
Dr Andrew C Aitchison wrote: On Tue, 8 Feb 2005, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? How often does the Xserver / DRM binary interface change - is it viable to just use the DRM in the running kernel ? I suppose this is really a question for one of the DRM lists but, is it a forlorn hope that the DRM could have a static binary interface to either the kernel or the X server ? (I guess that a moving kernel puts the former outside the control of the DRM project ?) There's a mixed answer (good news / bad news) to that question. AFAIK, the user-space client-side drivers and the DDX should work with a quite old DRM. That's the good news part. The bad news is that some features and / or bug fixes may not be available. For example, the current R200 driver works just fine with the DRM that ships with 2.4.21 kernel, but a couple security fixes and support for tiled framebuffers is missing. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. If we import the current DRM trunk code, there are three linux directories. 1. linuxfor 2.4 kernels (monolithic) 2. linux-2.6for 2.6 kernels (monolithic) 3. linux-core for 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsd monolithic 2. bsd-core modular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. If we import the current DRM trunk code, there are three linux directories. 1. linux for 2.4 kernels (monolithic) 2. linux-2.6 for 2.6 kernels (monolithic) 3. linux-core for 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsd monolithic 2. bsd-coremodular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. At this point in our release cycle, the priorities are: 1st: It builds/runs and is reasonably stable on a good range of platforms. 2nd: It supports as many DRI features as possible consistent with the first priority. I don't think that even changing from the existing single Linux directory to two different kernel-specific directories is appropriate at this point in our release cycle. The time for such a change was before the feature freeze. If what we have now is too broken to be fixed without major structural changes, then it will need to be rolled back. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 06:40:07PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. If we import the current DRM trunk code, there are three linux directories. 1. linux for 2.4 kernels (monolithic) 2. linux-2.6 for 2.6 kernels (monolithic) 3. linux-corefor 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsd monolithic 2. bsd-core modular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. At this point in our release cycle, the priorities are: 1st: It builds/runs and is reasonably stable on a good range of platforms. 2nd: It supports as many DRI features as possible consistent with the first priority. I don't think that even changing from the existing single Linux directory to two different kernel-specific directories is appropriate at this point in our release cycle. The time for such a change was before the feature freeze. If what we have now is too broken to be fixed without major structural changes, then it will need to be rolled back. The fear is, if you roll back the DRM, then the drivers may need to be rolled back as well to support lesser features. Alan. ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Tue, Feb 08, 2005 at 11:52:27PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:40:07PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 11:24:43PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 06:17:50PM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 05:12:29PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:59:15AM -0500, David Dawes wrote: On Tue, Feb 08, 2005 at 04:40:42PM +, Alan Hourihane wrote: On Tue, Feb 08, 2005 at 11:32:56AM -0500, David Dawes wrote: It looks like the DRM kernel source in xc/extras/drm is broken and incomplete, especially for BSD platforms. The Linux version only appears to build for a narrow range of kernels, and this either needs to be fixed, or the minimum kernel requirements enforced in the Makefile. Perhaps we'll have to roll back to an older version that does build? I suspect pulling in a newer snapshot would be better, although it's a little more complicated now because the drm has split out support for linux 2.4 and 2.6 kernels is separate subdirectories. Does the build automatically figure out which to use based on the kernel version, and what range of kernels has it been verified on? No. Any imports/updates need to address our requirements in this regard. If we import the current DRM trunk code, there are three linux directories. 1. linuxfor 2.4 kernels (monolithic) 2. linux-2.6for 2.6 kernels (monolithic) 3. linux-core for 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsd monolithic 2. bsd-core modular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. At this point in our release cycle, the priorities are: 1st: It builds/runs and is reasonably stable on a good range of platforms. 2nd: It supports as many DRI features as possible consistent with the first priority. I don't think that even changing from the existing single Linux directory to two different kernel-specific directories is appropriate at this point in our release cycle. The time for such a change was before the feature freeze. If what we have now is too broken to be fixed without major structural changes, then it will need to be rolled back. The fear is, if you roll back the DRM, then the drivers may need to be rolled back as well to support lesser features. Some have said here today that the drivers can adapt to older DRM versions. That's how it should be, but I don't know if it is true or not. I've seen some things in my initial testing that may cast some doubt on it, but there were too many other variables to be certain without followup. It would clearly be preferable to have a recent version that works. Is there a known recent stable/working version? From my point of view the fear is, updating to the latest version, adapting to its structural changes, and finding that the result is no better. David ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
Re: DRM kernel source broken/incomplete
On Wednesday 09 of February 2005 00:24, Alan Hourihane wrote: If we import the current DRM trunk code, there are three linux directories. 1. linux for 2.4 kernels (monolithic) 2. linux-2.6 for 2.6 kernels (monolithic) 3. linux-core for 2.6 kernels with modular drm.ko and driver.ko and two for bsd 1. bsdmonolithic 2. bsd-core modular as above The -core are the new ones going forward and which I believe has been merged in linux 2.6.11. So, for now the linux-2.6, linux and bsd directories are the ones to stick with for stability. But things are changing. There'll be necessary build tweaks to select which directories are needed. In case it helps: on FreeBSD 5.3-STABLE with fresh checkout of drm CVS: directory bsd fails to compile while bsd-core compiles fine. From a bit of browsing in CVS it seems that 'bsd' directory is lagging quite a bit behind its linux counterpart (there is drmfntbl-0-0-2-branch that hasn't yet been merged to HEAD as it was in linux dir which causes most of breakage). (drm source in XFree86 4.5 RC1 also fails to build). Dejan ___ Devel mailing list Devel@XFree86.Org http://XFree86.Org/mailman/listinfo/devel
