Re: [git pull] drm request 3
On Thursday 04 March 2010 18:53:32 Linus Torvalds wrote: On Fri, 5 Mar 2010, Dave Airlie wrote: I'm not saying it doesn't happen in other drivers from time to time, but when it does its treated as regression, for nouveau and STAGING that isn't what the Nouveau project (which Stephane mostly speaks for) seems to want at this stage. The problem with at this stage is that the stage has apparently been on-going for several years. Even if Stepane doesn't care, people inside RedHat/Fedora must care. Are you guys simply planning on never supporting F12 with 2.6.34? I'd expect it to be a _major_ pain to have that whole hardcoded X and kernel must always change in lockstep. And the sad part is, it would be so nice if the X server would just dlopen the right thing automatically, so that the low-level driver wouldn't even need to care. It already does the whole discover which driver to load part, wouldn't it be nice if that code had automatic versioning too, and then a low-level driver really wouldn't have to care, everything would automatically do the right thing just when the version changes. Of course, the distro would still have to make all the different versions of libdrm available to users, but now updating one wouldn't screw over the others. So if you had a known-good setup with nouveau-0.0.15, you could install a nouveau-0.0.16 thing and _know_ that it won't affect that previous install at all. And yeah, I realize that those version numbers are wrong. Normal library versioning rules about patchlevel not changing semantics are obviously broken here. But maybe the rules could even try to first start with the exact version, ie do a driver-x.y.z.so load, then a driver-x.y.so load, then a driver-x.so load and finally a driver.so load. But I guess that nothing even does that drmGetVersion() until the nouveau driver has already been loaded. Which kind of forces the low-level drivers to do any such versioning on their own. But wouldn't it be nice if something like this was done at a higher level, so that the drivers really wouldn't even need to care? Why not support a _minimal_ ABI that will always let X start with nouveau? Having X working does not mean that all forms of acceleration have to work too. If X starts, even if is slow, users can easily check logs which should have a message saying 'ABI change - upgrade your ...'. Thoughts? Ed Tomlinson -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm tree.
On Monday 21 September 2009 10:17:59 Alex Deucher wrote: On Mon, Sep 21, 2009 at 7:59 AM, Ed Tomlinson e...@aei.ca wrote: On Monday 21 September 2009 01:12:54 Dave Airlie wrote: Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains the main chunk of the drm changes for 2.6.32, I think Eric has been on holidays for a week so I'd expect some more Intel changes incoming in the merge window. It also contains a few merges for things that were conflicting with things I sent to you via the drm-fixes tree, but they weren't always trivial. Major highlights core drm/non-kms: move mga/r128/radeon to firmware loader - major LOC churn, decreases in-memory radeon module footprint quite a bit. r600 3D support in non-kms mode. Dave, What user space stuff (xorg/mesa) is required to use the R300 3D? r300 3D has been available for years. If you mean r600 3D, you need xf86-video-ati 6.12.4 or newer and mesa from git master. Alex Thanks, I did mean R600. Ed VGA arbitration support for core drm and kms (was waiting for jbarnes tree to land). core KMS: add support for GTF/CVT/DMT modes, gets us a long way towards X merge intel and radeon kms framebuffer implementations for sanity. radeon KMS: R600 KMS support + acceleration support. move to generating the safe register tables with a script. radeon tv-out supported ported from userspace rn50/r100/r200 command submission trackers added intel: some IGDNG fixes important fix for wrapping at end of ring more SDVO tv-out support dynamic clocking support -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [git pull] drm tree.
On Monday 21 September 2009 01:12:54 Dave Airlie wrote: Hi Linus, Please pull the 'drm-linus' branch from ssh://master.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6.git drm-linus This contains the main chunk of the drm changes for 2.6.32, I think Eric has been on holidays for a week so I'd expect some more Intel changes incoming in the merge window. It also contains a few merges for things that were conflicting with things I sent to you via the drm-fixes tree, but they weren't always trivial. Major highlights core drm/non-kms: move mga/r128/radeon to firmware loader - major LOC churn, decreases in-memory radeon module footprint quite a bit. r600 3D support in non-kms mode. Dave, What user space stuff (xorg/mesa) is required to use the R300 3D? TIA, Ed Tomlinson VGA arbitration support for core drm and kms (was waiting for jbarnes tree to land). core KMS: add support for GTF/CVT/DMT modes, gets us a long way towards X merge intel and radeon kms framebuffer implementations for sanity. radeon KMS: R600 KMS support + acceleration support. move to generating the safe register tables with a script. radeon tv-out supported ported from userspace rn50/r100/r200 command submission trackers added intel: some IGDNG fixes important fix for wrapping at end of ring more SDVO tv-out support dynamic clocking support -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
