On Fri, Aug 1, 2008 at 2:13 PM, Keith Packard <[EMAIL PROTECTED]> wrote: > On Fri, 2008-08-01 at 18:48 +0200, Jakob Bornecrantz wrote: > >> The basic fault here is that you have added a driver specific flag to a >> generic >> ioctl/syscall. Which the last time I checked we didn't want. For example on >> PCIE Radeon there is no GTT to map, so bit 31 makes no sense there. > > The GEM MMAP ioctl is driver-specific, not generic for precisely this > reason.
I think Jakob has a point though. From your first post in this thread: "We expose mmap ioctls on the gem objects, and I'd like to use the same basic mechanism; when (if?) gem objects become "real" files, we would want to continue using the same interface. I suggest creating two mmap windows for main memory objects:" Are you saying that you're not planning to make the mmap ioctl a real mmap syscall when/if that's feasible or that it's okay to add intel-gem specific bits to the mmap arguments? I recall Thomas asking for a flags argument to the GEM create ioctl... cheers, Kristian ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
