Re: Xshape extension
Carsten Haitzler (The Rasterman) escreveu: xshape in my experience works perfectly - so you can pretty much discount bugs there. the simplest way to use it is XShapeCombineMask() where you create a 1bit pixmap where 0 bits are "transparent" and 1 bits are solid - draw it, fill it then set the shape for your window. the pixmap is no longer needed after you set the mask as it is converted into a list of rectangles so you can free it. other ways are to set the rectangle list yourself with XShapeCombineRectangles() (always set the rectangle ordering to unordered to avoid bugs). you can also use the shapes of other windows and merge/combine them (if another window already has the shape you want - eg a window manager wants to use the client window's shape and COMBINE it with its own frame window shape) using XShapeCombineShape(). some of the best code u'll find inside windowmanagers to do some of this :) pick any one. enlightenment does a fair bit with shapes for example. :) other wm's should be equally good. Hello Carsten. I'm the brazilian guy you met in 2002 at LCA, I don't know if you remember me. Thanks for the answer, I'll check enlightenment out. What's bugging me is that I'm quite sure I'm creating the mask correctly but looks like when I apply quick changes to the mask on the window, it stops to respond correctly but as you said, XShape should work fine so I'll double check if I'm really not messing the mask. Anyway, thanks for the tips. Adilson. -- Nullum magnum ingenium sine mixtura dementiae fuit - Seneca ___ 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
Alert, This is your second notification.
610118802905 Your mtg process is approved, for rates starting at the lowest fixed rate=
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
XFree86 4.5.0 RC1 (4.4.99.901)
The first XFree86 4.5.0 release candidate is available. Source and some binaries can be found at: ftp://ftp.xfree86.org/pub/XFree86/snapshots/4.4.99.901/ Documentation is at: http://www.xfree86.org/4.4.99.901/ Preview documentation for 4.5.0 is at: http://www.xfree86.org/~dawes/pre-4.5/ This release candidate marks the start of the intense testing phase for the 4.5.0 release. Most platform build/packaging issues should be resolved at this point, but if you run into any, let us know. The focus now is on run-time and correctness testing. Run-time testing is basically running the release candidate in your usual environment and reporting problems you find. Correctness testing consists of running the xtest suite. If you are interested in running the xtest suite, you can find the source with this release candidate. Information about how to build and run the xtest suite can be found in the test/xsuite/NOTES.xf86 file that is part of the xtest source. If you find any run-time or correctness problems, or run into any problems building or running the xtest suite, please report details here. If you haven't already done so, this release candidate would be a good time to test the XFree86 automatic configuration feature. It was first available with the 4.4.0 release, and has been improved since then. It currently works on most Linux, FreeBSD, NetBSD, OpenBSD and Solaris/ix86 platforms. You can try it out easily without affecting your existing configuration. The quickest way to do this is to run: XFree86 -autoconfig which will start up the XFree86 server without any applications. You should see the familiar X stipple background and be able to move the X cursor. You can exit this with CtrlAltBackspace. If that looks OK, try running your usual X session with: startx -- -autoconfig If you find any problems with this, please send details. The goal of the automatic configuration feature is for the XFree86 server to run in a usable form without any user intervention on a majority of platforms. It works by maximising the amount of configuration that can automatically be detected within the XFree86 server, by using an external rule-based mechanism to make the best choices of video driver and video driver options, and by providing fallbacks to ensure that the XFree86 server will run in some form in nearly all situations. The TODO list for the 4.5.0 release is: 1. Testing, testing, and more testing. 2. Update the documentation, especially the release notes. If you have updates for the documentation, send them here. 3. Resolve issues with the DRM source. 4. Did I mention testing? :-) Enjoy! 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
