[Bug 23234] radeon , kms , xrandr - mouse disspaears on secondary screen
http://bugs.freedesktop.org/show_bug.cgi?id=23234 --- Comment #14 from Michael Mair-Keimberger bu9zi...@gmail.com 2009-11-08 02:39:41 PST --- I can confirm, that this problem is now fixed. Tried it with the latest kernel (sys-kernel/git-sources-2.6.32_rc6-r3) and a git-checkout from today (drm, xf86-vdieo-ati, mesa). I'm using xorg-server 1.6.5. So far no problems. KMS is really awesome :D -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24131] radeon_bo_legacy.c:207: legacy_is_pending: Assertion `bo_legacy-is_pending = bo-cref' failed
http://bugs.freedesktop.org/show_bug.cgi?id=24131 Julien Cristau jcris...@debian.org changed: What|Removed |Added CC||christian.blaic...@googlemai ||l.com --- Comment #14 from Julien Cristau jcris...@debian.org 2009-11-08 03:00:40 PST --- *** Bug 24822 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Fri, Nov 6, 2009 at 22:23:46 +0100, Jerome Glisse wrote: I think Joe user will install the kernel-header package of its distribution, and libdrm should detect at configure time kernel header version and people should take care to only enable new libdrm stuff when libdrm find the proper header. This imply that we are studious coder and don't forget about that when adding new features needing new headers :) For instance if it detects header with no KMS stuff it should loudly print at end of configure that it disable KMS support. That would lead to a hell of ifdefs in libdrm. I think keeping copies of the latest kernel drm headers in the libdrm repo and tarballs would be best. Cheers, Julien -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24600] 32/64 (ioctl) issues with radeon kms
http://bugs.freedesktop.org/show_bug.cgi?id=24600 Michael Tokarev m...@tls.msk.ru changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from Michael Tokarev m...@tls.msk.ru 2009-11-08 07:49:51 PST --- It appears that in 2.6.32-rc6 the issue is gone. So I'm closing this bug. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23234] radeon , kms , xrandr - mouse disspaears on secondary screen
http://bugs.freedesktop.org/show_bug.cgi?id=23234 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. This is why I've also argued against having libdrm not install the ioctl headers. It seems like the argument is mostly that having libdrm keep a copy of the kernel headers in the repo is bad because people might cp the file wrong. If the cost of not keeping them in the repo is having the libdrm and its consumers be ifdef hell, I will keep a cp in the repo. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. This is why I've also argued against having libdrm not install the ioctl headers. It seems like the argument is mostly that having libdrm keep a copy of the kernel headers in the repo is bad because people might cp the file wrong. If the cost of not keeping them in the repo is having the libdrm and its consumers be ifdef hell, I will keep a cp in the repo. Now I don't get it. You say versioning libdrm headers is the right thing? Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24950] Build of mesa-git fails sometimes (no rule to make target compiler/libr300compiler.a)
http://bugs.freedesktop.org/show_bug.cgi?id=24950 --- Comment #5 from Dan Nicholson dbn.li...@gmail.com 2009-11-08 12:49:54 PST --- Created an attachment (id=31050) -- (http://bugs.freedesktop.org/attachment.cgi?id=31050) Build in subdirs before linking driver Can you try the attached patch? It should ensure that the subdirs are done building before the driver is linked. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? -- Eric Anholt e...@anholt.net eric.anh...@intel.com signature.asc Description: This is a digitally signed message part -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime. People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. If the only reason not to merge the libdrm into the kernel tree is because you have a difficult time finding a libdrm for old kernels (and only during the transition), well I'd say that means there's no real problem here. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24950] Build of mesa-git fails sometimes (no rule to make target compiler/libr300compiler.a)
http://bugs.freedesktop.org/show_bug.cgi?id=24950 --- Comment #6 from Konstantin ernestoguev...@gmx.net 2009-11-08 15:21:29 PST --- Created an attachment (id=31054) -- (http://bugs.freedesktop.org/attachment.cgi?id=31054) build.log with patch by Dan Nicholson Nope, the patch didn't help, see attached build.log. (I named the patch mesa-build-subdirs-first.patch, which is applied at the beginning - I also checked the code for the change) -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 23:33, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 20:02, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: On Sun, Nov 8, 2009 at 19:18, Eric Anholt e...@anholt.net wrote: On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: 2009/11/6 Kristian Høgsberg k...@bitplanet.net: Hi, This has come up a few time and it's something I think makes a lot of sense. Since all driver development (afaik) now happens in linux kernel tree, it makes sense to drop the driver bits from the drm.git repo. I've put up a repo under Actually, I don't think a separate libdrm makes much sense. We don't want to add yet another outside component and ask ourselves questions like how do I maintain compatibility (which, incidentally, have already been raised). Given this, IMO libdrm live somewhere alongside the kernel. Furthermore when pulling outside stuff we driver devs can do a kernel+DRM+libdrm pull at the same time which is a win. And also users don't have to wonder where/how to pick the right libdrm. You get the right one with your kernel. This is a bad idea. libdrm with the kernel means that users and distributions can't trivially update libdrm. So all of the users of libdrm end up being an ifdeffed nightmare of both compile-time and runtime detection. Why do you need to update libdrm separately from the kernel? Is there so much that's in libdrm that does not also require a new drm? Newer libdrm functionality usually also requires a new drm... Our code used to be that way before we fixed libdrm to be only use kernel code that's going upstream, and never regress it. Things have improved in the last few years for upstream drivers, and I don't want to regress them with moving libdrm to the kernel. Again I don't see what kind of changes you have in mind. You just say regress. I need to enable a new feature in the driver by relying on a new kernel interface. This happens at least once per kernel version (every ~3 months), and we're currently retaining backwards compatibility to kernels a year old. Today, this ends up easy. In my driver components (Mesa and xf86-video-intel) I pkg-config version assert on on the new version of libdrm with the new headers. I do a runtime detection of the new feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl interface as appropriate. An example of this would be kernel_exec_fencing in 2.6.29, which impacts many files in the driver. If userland doesn't get to assert new libdrm/interface header presence, then in addition to the runtime detection, I have to ifdef all use of the new interfaces. Now, if we screw up the ifdefs (which used to happen regularly), people's builds don't work because they have old kernels. People obviously thought that situation sucked in the past, as we saw in both the intel and radeon drivers where pieces of the drm headers were just spammed right into the files using them, under ifdefs. This did result in actual divergence from the kernel definitions and real bugs, unlike today's situation where diff can confirm for me that we're using exactly the same interfaces between userland and kernel. Okay, well in any case nothing in what you mentioned prevents the libdrm from living with the kernel. We could keep the compat stuff here, and we still have the advantages I mentioned. So is there any other reason for not putting it with the kernel? So you're saying that people building their distribution on 2.6.29 would have to pull down linux-2.6 from master to build and install libdrm? People with old kernels can pick an old libdrm from some place else in the meantime. People with 2.6.32 don't have to grab anything more as libdrm came with their kernel already. If the only reason not to merge the libdrm into the kernel tree is because you have a difficult time finding a libdrm for old kernels (and only during the transition), well I'd say that means there's no real problem here. There are any number of changes that may occur in libdrm that do not impact the KBI and users should be able to get those features/bug fixes without needing a new kernel. robert. Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___
[PATCH] drm/i915: Fix sync to vblank when VGA output is turned off
In current vblank-wait implementation, if we turn off VGA output,
drm_wait_vblank will still wait on the disabled pipe until timeout,
because vblank on the pipe is assumed be enabled. This would cause
slow system response on some system such as moblin.
This patch resolve the issue by adding a drm helper function
drm_vblank_off which explicitly clear vblank_enabled[crtc], wake up
any waiting queue and save last vblank counter before turning off
crtc. It also slightly change drm_vblank_get to ensure that we will
will return immediately if trying to wait on a disabled pipe.
Signed-off-by: Li Peng peng...@intel.com
---
drivers/gpu/drm/drm_irq.c| 34 ++
drivers/gpu/drm/i915/intel_display.c |1 +
include/drm/drmP.h |1 +
3 files changed, 28 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 0a6f0b3..332d743 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -429,15 +429,21 @@ int drm_vblank_get(struct drm_device *dev, int crtc)
spin_lock_irqsave(dev-vbl_lock, irqflags);
/* Going from 0-1 means we have to enable interrupts again */
- if (atomic_add_return(1, dev-vblank_refcount[crtc]) == 1
- !dev-vblank_enabled[crtc]) {
- ret = dev-driver-enable_vblank(dev, crtc);
- DRM_DEBUG(enabling vblank on crtc %d, ret: %d\n, crtc, ret);
- if (ret)
+ if (atomic_add_return(1, dev-vblank_refcount[crtc]) == 1) {
+ if (!dev-vblank_enabled[crtc]) {
+ ret = dev-driver-enable_vblank(dev, crtc);
+ DRM_DEBUG(enabling vblank on crtc %d, ret: %d\n,
crtc, ret);
+ if (ret)
+ atomic_dec(dev-vblank_refcount[crtc]);
+ else {
+ dev-vblank_enabled[crtc] = 1;
+ drm_update_vblank_count(dev, crtc);
+ }
+ }
+ } else {
+ if (!dev-vblank_enabled[crtc]) {
atomic_dec(dev-vblank_refcount[crtc]);
- else {
- dev-vblank_enabled[crtc] = 1;
- drm_update_vblank_count(dev, crtc);
+ ret = -EINVAL;
}
}
spin_unlock_irqrestore(dev-vbl_lock, irqflags);
@@ -464,6 +470,18 @@ void drm_vblank_put(struct drm_device *dev, int crtc)
}
EXPORT_SYMBOL(drm_vblank_put);
+void drm_vblank_off(struct drm_device *dev, int crtc)
+{
+ unsigned long irqflags;
+
+ spin_lock_irqsave(dev-vbl_lock, irqflags);
+ DRM_WAKEUP(dev-vbl_queue[crtc]);
+ dev-vblank_enabled[crtc] = 0;
+ dev-last_vblank[crtc] = dev-driver-get_vblank_counter(dev, crtc);
+ spin_unlock_irqrestore(dev-vbl_lock, irqflags);
+}
+EXPORT_SYMBOL(drm_vblank_off);
+
/**
* drm_vblank_pre_modeset - account for vblanks across mode sets
* @dev: DRM device
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3ba6546..962b72b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1848,6 +1848,7 @@ static void i9xx_crtc_dpms(struct drm_crtc *crtc, int
mode)
intel_update_watermarks(dev);
/* Give the overlay scaler a chance to disable if it's on this
pipe */
//intel_crtc_dpms_video(crtc, FALSE); TODO
+ drm_vblank_off(dev, pipe);
if (dev_priv-cfb_plane == plane
dev_priv-display.disable_fbc)
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c8e64bb..9d3d684 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -1295,6 +1295,7 @@ extern u32 drm_vblank_count(struct drm_device *dev, int
crtc);
extern void drm_handle_vblank(struct drm_device *dev, int crtc);
extern int drm_vblank_get(struct drm_device *dev, int crtc);
extern void drm_vblank_put(struct drm_device *dev, int crtc);
+extern void drm_vblank_off(struct drm_device *dev, int crtc);
extern void drm_vblank_cleanup(struct drm_device *dev);
/* Modesetting support */
extern void drm_vblank_pre_modeset(struct drm_device *dev, int crtc);
--
1.6.1.3
--
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
