Re: [git pull] drm
On Thu, Dec 10, 2009 at 2:49 PM, Pekka Paalanen wrote: > The big question is what we call ctxprogs: binary blobs that are > clearly executable, running somewhere in the GPU. No-one seems > to know, if those are copyrightable, or if they can be redistributed. > In their current form, they have been recorded from the nvidia > proprietary driver using mmiotrace, and copied verbatim for each > card type. > > Would you be willing to pull that kind of stuff into Linux? > > I would not even dare sending them to the Linux firmware > repository, since they have some license requirements, too. This seems similar to the unfortunate situation with the b43 wireless card firmware. Broadcom refuses to provide the firmware under a redistributable license (or even as files separate from their proprietary drivers). This did not stop b43 from being included in Linux. Distributions have dealt with it by providing a script that downloads the proprietary driver and extracts the firmware from it to files in /lib/firmware. Do you think that a similar solution for nouveau would be legally problematic? Or is the issue technical, since you mention that the ctxprogs were obtained by mmiotrace, instead of a more straightforward extraction from the binary driver blobs? -- Will Dyson -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] new radeon memory map fixes
On 1/26/06, Benjamin Herrenschmidt <[EMAIL PROTECTED]> wrote: > On Thu, 2006-01-26 at 10:43 +1100, Benjamin Herrenschmidt wrote: > > > Xorg driver patch: > > http://gate.crashing.org/~benh/radeon-memmap-7.0-2.diff > > > > DRM patch: > > http://gate.crashing.org/~benh/radeon-memmap-drm-1.diff > > The DRM patch had issues. Here's a new version that fixes them though > it would be useful to test it with earlier userland DRI (for the DRM > patch to have any effect, though, it must be run with a patches X driver > as well). > > http://gate.crashing.org/~benh/radeon-memmap-drm-3.diff I tested this patch on my amd64 debian box w/ x.org 6.9 (unpatched). No problems at all (as expected). I'll try to test the X driver patch soon, but I'm not sure exactly when I'll have time. -- Will Dyson --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Where/how to start implementing vertical retrace interrupt interface?
On 7/2/05, Peter Ronnquist <[EMAIL PROTECTED]> wrote: I've added the dri-devel and xorg mailing lists to the cc: list. > If I have understood things correctly then X/x.org can > not provide a flicker free update of the graphics on a > display since the linux kernel does not provide a way > to synchronize to the vertical retrace of a display. > > See > http://lists.freedesktop.org/archives/xdg/2004-August/004561.html I don't know if that was true at the time it was written, but today the DRM implements vblank wait for 3 drivers (mga, r128, and radeon). However, as far as I can tell, none of the X server's 2d drivers makes use of it. Perhaps some more work is needed to make the interface convient for the X server? If you have a card supported by one of these drivers, you can move on to getting the X server to use that capability to support vblank counters in the XSync extension. http://freedesktop.org/~jg/roadmap.html#mozTocId921013 Then you only need for toolkits (and/or individual apps) to get with the program and start using using XSync. > If a person with little previous experience of the > linux kernel source tree would like to start on such a > feature then how complicated do you believe it is to > implement? (days or months of work) > > Where in the kernel source is a good place to start > looking? linux/drivers/char/drm/ is where the kernel drivers for graphics cards live. Here is an overview of the different pieces of the current drm/dri/xserver graphics puzzle: http://dri.freedesktop.org/wiki/DriverFiles -- Will Dyson --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] 32-bit ioctl compatibility for CVS DRM
On Wed, 9 Mar 2005 22:55:04 +1100, Paul Mackerras <[EMAIL PROTECTED]> wrote: > Here is a patch that adds 32-bit ioctl compatibility code to the CVS > DRM (i.e. the drm CVS module at dri.freedesktop.org). > > I have taken a different approach to the problem of 32-bit map handles > this time. I only generate a fake 32-bit handle for _DRM_SHM mappings > as before, but now I put the 32-bit handle in map->offset for those > mappings (previously map->offset and map->handle were the same for > _DRM_SHM mappings). This simplifies the code quite a bit. I built this against CVS DRM and a recent -bk kernel (just prior to 2.6.12-rc1) on amd64. I had to merge support for the recent agp bridge changes into the CVS DRM, but I don't think that should have affected the ioctl32 bits. Setup: Distro: Debian unstable pure64 Graphics card: radeon9200 Kernel: -bk snapshot from just before 2.6.12-rc1 (plus cvs drm, plus the above patch) X server used in tests: Xorg 6.8.2 Results: 64-bit direct rendering clients are still quite happy with this patch. I've tested this with the libGL.so and r200_dri.so from Xorg 6.8.2 and with those from the debian XFree86 4.3 package. At some point soon, I'll make sure to actually run the XFree86 4.3 server and test that too. 32-bit direct rendering clients are also happy when run under a 32-bit X server. I've only tested the Xorg 6.8.2 server in 32-bit mode, however. I'll try and test the old 4.3 server sometime this week. -- Will Dyson --- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
