Hi, I'm using a few spare hours to get started working on the Savage DRM driver. I'm going to have to rewrite it from scratch. The current sarea definition is essentially copied from the MGA driver and the only 3 driver-specific ioctls are not (and probably won't be) used by the current 2D/3D drivers. ;-)
To get started I have to clean up the savage_sarea structure and define structures for ioctl arguments and such stuff. I looked around in some existing DRM header files, mostly MGA. At first I was a bit confused about how things fit together and recent comments about fixing 64-bit issues and reorganizing DRM header files added to that confusion. I'd like to get this DRM right from the start. So any advice would be welcome. Below is my current understanding about how things _should_ be. === Header files in the DRM === drm.h: driver-independent types and definitions for the 3D driver to communicate with the DRM. drmP.h: driver-independent internal types and definitions. savage_drm.h: any definitions needed by the 3D driver to communicate with the DRM (sarea, sarea defines, ioctl parameter structures). Someone recently proposed to use a "sanitized" copy of this file (and probably drm.h) in the 3D driver instead of the kernel header file. That would mean that these definitions have to be kept in sync in 3 places: kernel, sanitized user-space copy and Xserver (see below). Does that make sense? savage_drv.h: driver-internal data types like the dev_private structure and function prototypes, some macros for BCI access. savage.h: DRM template customization === Header files in the Xserver === savage_sarea.h: Basically a copy of the sarea defines and sarea structure in the kernel but with different naming conventions. I vaguely remember that this was because of XFree86's policy not to use external header files or something such. savage_common.h: Ioctl parameter structures with XFree86 naming conventions. Same rationale as for savage_sarea.h, I guess. The sarea defines are protected by a macro __SAVAGE_SAREA_DEFINES__. This looks like it should be possible to include savage_sarea.h and savage_drm.h in the same source file. I havn't found any example of that though. Is this an artifact from early DRI/DRM days? === 64bit issues === Basically any fields in data structures shared between kernel and user-space must have a fixed size in order to allow 32-bit user space to work with a 64-bit kernel. Is that correct? Then what are the right types (u32, __u32, uint32, ...?) that are available in both the kernel (possibly linux and BSD) and user-space? Or if we're not going to share header files between kernel tree and 3D drivers, then what types would be used in the kernel and which types in user-space? For keeping the DRM portable among OS's, should fixed-size number types be defined in drm.h/drmP.h? TIA for any feedback, Felix | Felix Kühling <[EMAIL PROTECTED]> http://fxk.de.vu | | PGP Fingerprint: 6A3C 9566 5B30 DDED 73C3 B152 151C 5CC1 D888 E595 | ------------------------------------------------------- This SF.Net email is sponsored by: SourceForge.net Broadband Sign-up now for SourceForge Broadband and get the fastest 6.0/768 connection for only $19.95/mo for the first 3 months! http://ads.osdn.com/?ad_id%62&alloc_ida84&op=click -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
