[Bug 2497] r200 dri driver: glut menues are broken in sw-tnl mode
Please do not reply to this email: if you want to comment on the bug, go to the URL shown below and enter yourcomments there. https://bugs.freedesktop.org/show_bug.cgi?id=2497 [EMAIL PROTECTED] changed: What|Removed |Added Summary|glut menues are broken in |r200 dri driver: glut menues |sw-tnl mode |are broken in sw-tnl mode -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. --- 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_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On Sul, 2005-07-03 at 05:04, Jon Smirl wrote: There are three DRI drivers with no DRM. What is up with these? gamma s3v trident trident was never finished s3v and gamma were both against old DRM and are not shipped in curren trees --- 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_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
Any ideas on what to call my DRM sysfs attribute which provides the name of the corresponding DRI library? I named it dri initially but that may not be descriptive enough. -- Jon Smirl [EMAIL PROTECTED] --- 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_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote: Shouldn't this just be a string you pull right out of a drm ioctl? I know the name currently lives in the server, but as with many things the server does I think that's a mistake. Binding EGL driver load to sysfs is not portable. The code is only in my Linux drivers. In your EGL app you specify something like :0. The generic code is wired to always load dri_egl.so for the :? syntax. dri_egl then figures out which screen corresponds to :0 and looks for the DRM sysfs entry. It then uses that to load the right DRI driver and passes control over. On Linux sysfs attributes and ioctls are very similar. It is now preferred on Linux to get simple things like this from a sysfs attribute instead of an ioctl since the sysfs attributes avoid 32/64 and endian issues. It is also easy for a human to see which driver the DRM module needs. -- Jon Smirl [EMAIL PROTECTED] --- 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_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On 7/3/05, Jon Smirl [EMAIL PROTECTED] wrote: Any ideas on what to call my DRM sysfs attribute which provides the name of the corresponding DRI library? I named it dri initially but that may not be descriptive enough. I called it dri_library_name, we can always change it. -- Jon Smirl [EMAIL PROTECTED] --- 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_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On Sunday 03 July 2005 12:31, Jon Smirl wrote: On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote: Shouldn't this just be a string you pull right out of a drm ioctl? I know the name currently lives in the server, but as with many things the server does I think that's a mistake. Binding EGL driver load to sysfs is not portable. The code is only in my Linux drivers. In your EGL app you specify something like :0. The generic code is wired to always load dri_egl.so for the :? syntax. dri_egl then figures out which screen corresponds to :0 and looks for the DRM sysfs entry. It then uses that to load the right DRI driver and passes control over. Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I was anticipating: - eglChooseDisplayMESA(display/0) - EGL translates to /dev/dri/card0, opens it - ioctl: what's the DRI driver name for this device? - kernel: i915 - EGL loads i915_dri.so, calls its egl setup - eglCreateContext notices the attached dri driver, does device setup I guess I don't see the point of loading one module to have it load another, particularly if that first module is always getting loaded. On Linux sysfs attributes and ioctls are very similar. It is now preferred on Linux to get simple things like this from a sysfs attribute instead of an ioctl since the sysfs attributes avoid 32/64 and endian issues. It is also easy for a human to see which driver the DRM module needs. The human should never have to care. There's going to need to be an ioctl for this _anyway_ if anyone ever implements this on non-Linux. We should really be avoiding OS-specific code paths in the driver as much as possible. That's why we have the abstract DRM interface to begin with. - ajax pgpTWRV79UQ9l.pgp Description: PGP signature
Re: DRI vs DRM
On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote: Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I was anticipating: - eglChooseDisplayMESA(display/0) - EGL translates to /dev/dri/card0, opens it - ioctl: what's the DRI driver name for this device? - kernel: i915 - EGL loads i915_dri.so, calls its egl setup - eglCreateContext notices the attached dri driver, does device setup I guess I don't see the point of loading one module to have it load another, particularly if that first module is always getting loaded. Brian wants to keep libEGL crossplatform and generic so this forces me into a third library. I'm putting all of the common code into the third library too. It contains code similar to miniglx.c -- Jon Smirl [EMAIL PROTECTED] --- 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_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
Jon Smirl wrote: On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote: Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I was anticipating: - eglChooseDisplayMESA(display/0) - EGL translates to /dev/dri/card0, opens it - ioctl: what's the DRI driver name for this device? - kernel: i915 - EGL loads i915_dri.so, calls its egl setup - eglCreateContext notices the attached dri driver, does device setup I guess I don't see the point of loading one module to have it load another, particularly if that first module is always getting loaded. Brian wants to keep libEGL crossplatform and generic so this forces me into a third library. I said I'd like to keep the src/egl/main/ directory cross-platform. The Linux version of libEGL.so could certainly have additional code in it. But I'm certainly open to ideas. I just don't have much time to spend on this project. I'm putting all of the common code into the third library too. It contains code similar to miniglx.c -Brian --- 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_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On Sunday 03 July 2005 18:40, Brian Paul wrote: I said I'd like to keep the src/egl/main/ directory cross-platform. The Linux version of libEGL.so could certainly have additional code in it. But I'm certainly open to ideas. I just don't have much time to spend on this project. I'm still not entirely convinced the EGL API belongs anywhere but libGL. Is there a strong motivator for libEGL? - ajax pgpVyyoLy0wXr.pgp Description: PGP signature
Re: DRI vs DRM
Title: Re: DRI vs DRM There is a standard name the library. See Section 8.2 - Packaging/Libraries of the OpenGL|ES spec on Khronos' web page. It should be libGLES_xx.so where xx is CM or CL. Regards... Matthew -- Blackberry-Sent Matthew Tippett Acting Engineering Manager, Linux Software Engineering ATI Technologies Inc. Ph: +1 905 882 2600 x8014 Cell: +1 416 671 0673 -Original Message- From: [EMAIL PROTECTED] [EMAIL PROTECTED] To: Brian Paul [EMAIL PROTECTED] CC: Jon Smirl [EMAIL PROTECTED]; dri-devel@lists.sourceforge.net dri-devel@lists.sourceforge.net Sent: Sun Jul 03 18:44:00 2005 Subject: Re: DRI vs DRM On Sunday 03 July 2005 18:40, Brian Paul wrote: I said I'd like to keep the src/egl/main/ directory cross-platform. The Linux version of libEGL.so could certainly have additional code in it. But I'm certainly open to ideas. I just don't have much time to spend on this project. I'm still not entirely convinced the EGL API belongs anywhere but libGL. Is there a strong motivator for libEGL? - ajax
Re: DRI vs DRM
On 7/3/05, Brian Paul [EMAIL PROTECTED] wrote: I said I'd like to keep the src/egl/main/ directory cross-platform. The Linux version of libEGL.so could certainly have additional code in it. But I'm certainly open to ideas. I just don't have much time to spend on this project. The code is in a separate library currently but it is not hard to merge it into the Linux version of libEGL. -- Jon Smirl [EMAIL PROTECTED] --- 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_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[2.6 patch] DRM: misc cleanup
I've seen that part of this is already in recent kernels. Below is as a FYI a version against 2.6.13-rc1-mm1. -- snip -- This patch contains the following cleanups: - make needlessly global functions static - remove the following unused global functions: - drm_fops.c: drm_read - i915_dma.c: i915_do_cleanup_pageflip Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- drivers/char/drm/ati_pcigart.c |2 drivers/char/drm/drmP.h| 22 --- drivers/char/drm/drm_auth.c|4 - drivers/char/drm/drm_bufs.c| 12 ++-- drivers/char/drm/drm_context.c |6 +- drivers/char/drm/drm_drv.c |9 ++- drivers/char/drm/drm_fops.c| 10 +-- drivers/char/drm/drm_irq.c |2 drivers/char/drm/drm_lock.c| 12 +++- drivers/char/drm/drm_proc.c|2 drivers/char/drm/drm_stub.c| 92 - drivers/char/drm/drm_vm.c | 10 ++- drivers/char/drm/i810_dma.c| 24 drivers/char/drm/i810_drv.h|1 drivers/char/drm/i830_dma.c| 20 +++ drivers/char/drm/i830_drv.c|2 drivers/char/drm/i830_drv.h|2 drivers/char/drm/i830_irq.c|4 - drivers/char/drm/i915_dma.c| 60 - drivers/char/drm/i915_drv.c|2 drivers/char/drm/i915_drv.h| 10 --- drivers/char/drm/i915_irq.c|4 - drivers/char/drm/r128_state.c |2 drivers/char/drm/via_ds.c |1 24 files changed, 137 insertions(+), 178 deletions(-) --- linux-2.6.12-rc2-mm3-full/drivers/char/drm/drmP.h.old 2005-04-18 03:54:16.0 +0200 +++ linux-2.6.12-rc2-mm3-full/drivers/char/drm/drmP.h 2005-04-18 03:54:49.0 +0200 @@ -774,8 +774,6 @@ /* Driver support (drm_drv.h) */ extern int drm_init(struct drm_driver *driver); extern void drm_exit(struct drm_driver *driver); -extern int drm_version(struct inode *inode, struct file *filp, - unsigned int cmd, unsigned long arg); extern int drm_ioctl(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg); extern long drm_compat_ioctl(struct file *filp, @@ -785,21 +783,13 @@ /* Device support (drm_fops.h) */ extern int drm_open(struct inode *inode, struct file *filp); extern int drm_stub_open(struct inode *inode, struct file *filp); -extern int drm_open_helper(struct inode *inode, struct file *filp, - drm_device_t *dev); extern int drm_flush(struct file *filp); extern int drm_fasync(int fd, struct file *filp, int on); extern int drm_release(struct inode *inode, struct file *filp); /* Mapping support (drm_vm.h) */ -extern void drm_vm_open(struct vm_area_struct *vma); -extern void drm_vm_close(struct vm_area_struct *vma); -extern void drm_vm_shm_close(struct vm_area_struct *vma); -extern int drm_mmap_dma(struct file *filp, - struct vm_area_struct *vma); extern int drm_mmap(struct file *filp, struct vm_area_struct *vma); extern unsigned int drm_poll(struct file *filp, struct poll_table_struct *wait); -extern ssize_t drm_read(struct file *filp, char __user *buf, size_t count, loff_t *off); /* Memory management support (drm_memory.h) */ #include drm_memory.h @@ -854,9 +844,6 @@ extern int drm_rmctx( struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg ); -extern int drm_context_switch(drm_device_t *dev, int old, int new); -extern int drm_context_switch_complete(drm_device_t *dev, int new); - extern int drm_ctxbitmap_init( drm_device_t *dev ); extern void drm_ctxbitmap_cleanup( drm_device_t *dev ); extern void drm_ctxbitmap_free( drm_device_t *dev, int ctx_handle ); @@ -874,9 +861,6 @@ /* Authentication IOCTL support (drm_auth.h) */ -extern int drm_add_magic(drm_device_t *dev, drm_file_t *priv, - drm_magic_t magic); -extern int drm_remove_magic(drm_device_t *dev, drm_magic_t magic); extern int drm_getmagic(struct inode *inode, struct file *filp, unsigned int cmd, unsigned long arg); extern int drm_authmagic(struct inode *inode, struct file *filp, @@ -893,13 +877,9 @@ unsigned int cmd, unsigned long arg); extern int drm_lock_take(__volatile__ unsigned int *lock, unsigned int context); -extern int drm_lock_transfer(drm_device_t *dev, - __volatile__ unsigned int *lock, -
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_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
Keith Whitwell writes:
Sounds good Paul. I think it's worthwhile to at least investigate this
as it'd be a cleaner result all round at the end.
Based on Egbert's comments about the use of an idr structure
restricting our choice of token values, I have taken an alternative
approach where I put the user token in the drm_map_list_t structure,
which is private to the kernel.
This patch is against the current DRM code in the kernel tree. The
DRM code in CVS looks a bit different and I'm not sure where it is up
to.
I am currently assigning completely arbitrary 32-bit tokens for maps
just to see how that works, and it seems to be fine on my G5 (which
has AGP and a radeon 9600 card). I think it would be preferable to
use Egbert's code which uses the map-offset value if it fits into 32
bits in the longer term.
I am also assigning 32-bit tokens even if CONFIG_COMPAT isn't
defined. For 64-bit kernels that don't have CONFIG_COMPAT defined, do
we still want to generate 32-bit tokens? We will have to if we make
the tokens passed between the X server and the client 32-bit.
If people don't like me adding the dev-agp_buffer_token field, the
alternative would be to search the dev-maplist list to find the token
for dev-agp_buffer_list in drm_mapbufs. I didn't see the point in
throwing away the token and then having to search for it, though.
I have incorporated the drm_core_findmap_by_base from Egbert's patch.
Nothing in the kernel tree's DRM seems to need it at present.
Comments?
Paul.
diff -urN linux-2.6/drivers/char/drm/drmP.h g5-ppc64-drm/drivers/char/drm/drmP.h
--- linux-2.6/drivers/char/drm/drmP.h 2005-06-27 13:26:27.0 +1000
+++ g5-ppc64-drm/drivers/char/drm/drmP.h2005-07-04 08:56:35.0
+1000
@@ -531,6 +531,7 @@
typedef struct drm_map_list {
struct list_headhead; /** list head */
drm_map_t *map; /** mapping */
+ unsigned intuser_token;
} drm_map_list_t;
typedef drm_map_t drm_local_map_t;
@@ -736,6 +737,7 @@
structdrm_driver *driver;
drm_local_map_t *agp_buffer_map;
+ unsigned int agp_buffer_token;
drm_head_t primary; /** primary screen head */
} drm_device_t;
@@ -1035,16 +1037,23 @@
drm_ioremapfree( map-handle, map-size, dev );
}
-static __inline__ struct drm_map *drm_core_findmap(struct drm_device *dev,
unsigned long offset)
+static __inline__ struct drm_map *drm_core_findmap(struct drm_device *dev,
unsigned int token)
{
- struct list_head *_list;
- list_for_each( _list, dev-maplist-head ) {
- drm_map_list_t *_entry = list_entry( _list, drm_map_list_t,
head );
- if ( _entry-map
-_entry-map-offset == offset ) {
+ drm_map_list_t *_entry;
+
+ list_for_each_entry(_entry, dev-maplist-head, head)
+ if (_entry-user_token == token)
+ return _entry-map;
+ return NULL;
+}
+
+static __inline__ struct drm_map *drm_core_findmap_by_base(struct drm_device
*dev, unsigned long offset)
+{
+ drm_map_list_t *_entry;
+
+ list_for_each_entry(_entry, dev-maplist-head, head)
+ if (_entry-map _entry-map-offset == offset)
return _entry-map;
- }
- }
return NULL;
}
diff -urN linux-2.6/drivers/char/drm/drm_bufs.c
g5-ppc64-drm/drivers/char/drm/drm_bufs.c
--- linux-2.6/drivers/char/drm/drm_bufs.c 2005-06-27 13:26:27.0
+1000
+++ g5-ppc64-drm/drivers/char/drm/drm_bufs.c2005-07-04 10:43:39.0
+1000
@@ -60,14 +60,10 @@
}
EXPORT_SYMBOL(drm_order);
-#ifdef CONFIG_COMPAT
/*
- * Used to allocate 32-bit handles for _DRM_SHM regions
- * The 0x1000 value is chosen to be out of the way of
- * FB/register and GART physical addresses.
+ * Used to allocate 32-bit handles for mappings.
*/
static unsigned int map32_handle = 0x1000;
-#endif
/**
* Ioctl to specify a range of memory that is available for mapping by a
non-root process.
@@ -90,6 +86,7 @@
drm_map_t *map;
drm_map_t __user *argp = (void __user *)arg;
drm_map_list_t *list;
+ unsigned long handle;
if ( !(filp-f_mode 3) ) return -EACCES; /* Require read/write */
@@ -196,17 +193,16 @@
down(dev-struct_sem);
list_add(list-head, dev-maplist-head);
-#ifdef CONFIG_COMPAT
- /* Assign a 32-bit handle for _DRM_SHM mappings */
+
+ /* Assign a 32-bit handle */
/* We do it here so that dev-struct_sem protects the increment */
- if (map-type == _DRM_SHM)
- map-offset = map32_handle += PAGE_SIZE;
-#endif
+ list-user_token = handle = map32_handle += PAGE_SIZE;
+
up(dev-struct_sem);
if ( copy_to_user( argp, map, sizeof(*map) ) )
return -EFAULT;
- if (copy_to_user(argp-handle, map-offset, sizeof(map-offset)))
+ if (put_user(handle,
Re: DRM map design
Jon Smirl writes: drmMap never cares about the handle since drmMap turns into mmap and mmap doesn't know about DRM maps. Huh? drm_mmap certainly does know about DRM maps. The trouble with using the offset returned by drmGetMap is that if your program is a 32-bit program running on a 64-bit kernel, and the kernel map-offset value for the map you want is 4G, then your 32-bit program will only see the bottom 32 bits of the offset value, and you end up with no way for your 32-bit program to mmap the map. That's why I am suggesting that the kernel should create a 32-bit token for each map and return it in the handle field, and the program should use that as the mmap offset when mmapping the map. Paul. --- 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_id=7477alloc_id=16492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
On 7/3/05, Paul Mackerras [EMAIL PROTECTED] wrote:
Jon Smirl writes:
drmMap never cares about the handle since drmMap turns into mmap and
mmap doesn't know about DRM maps.
Huh? drm_mmap certainly does know about DRM maps.
I see now that drmMap is overriding mmap's offset to pass in the
handle. So the reason my code is working is that the DRM handle and
offset are currently the same number.
int drmMap(int fd,
drm_handle_t handle,
drmSize size,
drmAddressPtr address)
{
static unsigned long pagesize_mask = 0;
if (fd 0) return -EINVAL;
if (!pagesize_mask)
pagesize_mask = getpagesize() - 1;
size = (size + pagesize_mask) ~pagesize_mask;
*address = mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, handle);
if (*address == MAP_FAILED) return -errno;
return 0;
}
I had switched to using offset since sarea had a handle of zero. A
handle of zero doesn't work because it trips this code at the
beginning of drm_mmap.
int drm_mmap(struct file *filp, struct vm_area_struct *vma)
{
DRM_DEBUG(start = 0x%lx, end = 0x%lx, offset = 0x%lx\n,
vma-vm_start, vma-vm_end, VM_OFFSET(vma));
if (!priv-authenticated)
return -EACCES;
/* We check for dma. On Apple's UniNorth, it's valid to have
* the AGP mapped at physical address 0
* --BenH.
*/
if (!VM_OFFSET(vma)
#if __OS_HAS_AGP
(!dev-agp
|| dev-agp-agp_info.device-vendor != PCI_VENDOR_ID_APPLE)
#endif
)
return drm_mmap_dma(filp, vma);
When I passed in sarea's handle I was ending up in drm_mmap_dma.
The trouble with using the offset returned by drmGetMap is that if
your program is a 32-bit program running on a 64-bit kernel, and the
kernel map-offset value for the map you want is 4G, then your
32-bit program will only see the bottom 32 bits of the offset value,
and you end up with no way for your 32-bit program to mmap the map.
That's why I am suggesting that the kernel should create a 32-bit
token for each map and return it in the handle field, and the program
should use that as the mmap offset when mmapping the map.
I'm fine with switching to true handles. I'm not really sure what the
check for 'dma' is looking for. But we need to fix sarea to have a
proper handle.
--
Jon Smirl
[EMAIL PROTECTED]
---
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_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
