On linux, drm_handle_t is typedef'd to an unsigned int; on other platforms, it is typedef'd to an unsigned long. On 64bit systems, this causes problems due to casting; it ends up being used as an off_t, which is 8 bytes; an unsigned int is only 4. You can see gcc spitting up warnings during the build here: http://bugs.debian.org/324560
drm_handle_t is deliberately 32-bit so that it is compatible between 32-bit and 64-bit servers, clients and the kernel. The kernel DRM code goes to some lengths to produce drm_handle_t values that fit in 32 bits even on 64 bit systems. drm_handle_t is not a pointer and should not be being cast to/from a pointer.
While it is nice that the kernel ensures that drm_map_t handles (and other handles) all fit within a 32bit integer so we can have a functional 32bit userspace with a 64bit kernel, I think it's a bit shortsighted to have the userspace library simply assume that this will always be the case in the kernel code. Why not have drm_handle_t be a 64bit integer on platforms that support it? Alternatively, why use a void* for drm_map_t and drm_ctx_priv_map_t's handles when you could use a drm_handle_t, an unsigned int, an unsigned long int, or an off_t?
Andres Salomon Do you still experience this issue with newer soft ? Please check the status of your issue.
drm_handle_t is still 'unsigned int', but it's also only present in legacy (pre-KMS) APIs, so, meh.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.