[ANNOUNCE] X.Org @ LinuxTag, Wiesbaden Germany
[ Announcement: European Linux Event - not limited to European contributors ] As announced before X.Org will be present on LinuxTag in Wiesbaden, Germany May 3 - 6, 2006 We are still looking for volunteers who whould like to demo some exciting new X-related technology (including MESA and DRM) or just hang out with other graphics people on the booth. To coordinate our effords there is a wiki page devoted to this: http://wiki.x.org/wiki/LinuxTagOrganization2006 If you would like to come and join us please use this page to register yourself as a participant or drop me an email at eich_at_freedesktop_org You will get a free exhibitors pass. Also there are free passes available you can give to your friends. It's a little bit over a week until the event starts so if you would like to participate and you are travelling by train there is opportunity to purchase a discount train ticket. If you need help with finding accomodations please let me know - I may be able to help you finding something. Cheers, Egbert. --- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
32bit builds of Mesa on 64bit platforms
The patch below allows 32bit builds of Mesa on 64bit (especially x86_64) systems. The '-m32' option for gcc/g++ should work with all versions of gcc = 3.0 - also on ia32. Egbert. Index: configs/linux-dri-x86 === RCS file: /cvs/mesa/Mesa/configs/linux-dri-x86,v retrieving revision 1.9 diff -u -r1.9 linux-dri-x86 --- configs/linux-dri-x86 25 Sep 2004 07:11:12 - 1.9 +++ configs/linux-dri-x86 13 Jul 2005 14:36:27 - @@ -10,3 +10,5 @@ ASM_FLAGS = -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM ASM_SOURCES = $(X86_SOURCES) +CC = gcc -m32 +CXX = g++ -m32 Index: src/mesa/drivers/dri/Makefile.template === RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/Makefile.template,v retrieving revision 1.23 diff -u -r1.23 Makefile.template --- src/mesa/drivers/dri/Makefile.template 28 May 2005 20:17:06 - 1.23 +++ src/mesa/drivers/dri/Makefile.template 13 Jul 2005 14:36:28 - @@ -80,7 +80,7 @@ $(LIBNAME): $(OBJECTS) $(MESA_MODULES) $(WINOBJ) Makefile $(TOP)/src/mesa/drivers/dri/Makefile.template rm -f $@ - gcc $(ARCH_FLAGS) -o $@ -shared $(OBJECTS) $(MESA_MODULES) $(WINOBJ) $(DRI_LIB_DEPS) + $(CC) $(ARCH_FLAGS) -o $@ -shared $(OBJECTS) $(MESA_MODULES) $(WINOBJ) $(DRI_LIB_DEPS) $(LIB_DIR)/$(LIBNAME): $(LIBNAME) --- 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
making type of handles in libdrm more consistent
The following patches make the type of handles in libdrm
more consistent.
They allow us to later change the type of drm_handle_t
from unsigned long to unsigned int to allow 32bit and 64bit
clients and Xservers to share data structures.
Included are two patches: one for libdrm as part of DRM
and one for the libdrm parts (xf86drm.[ch]) in Mesa.
Once this has gotten accepted I will commit these files
in X myself.
Egbert.
Index: libdrm/xf86drm.c
===
RCS file: /cvs/dri/drm/libdrm/xf86drm.c,v
retrieving revision 1.51
diff -u -r1.51 xf86drm.c
--- libdrm/xf86drm.c4 Apr 2005 04:08:29 - 1.51
+++ libdrm/xf86drm.c15 Jul 2005 10:30:22 -
@@ -888,7 +888,7 @@
map.type= type;
map.flags = flags;
if (ioctl(fd, DRM_IOCTL_ADD_MAP, map)) return -errno;
-if (handle) *handle = (drm_handle_t)map.handle;
+if (handle) *handle = (drm_handle_t)(unsigned long)map.handle;
return 0;
}
@@ -896,7 +896,7 @@
{
drm_map_t map;
-map.handle = (void *)handle;
+map.handle = (void *)(unsigned long)handle;
if(ioctl(fd, DRM_IOCTL_RM_MAP, map)) return -errno;
return 0;
@@ -1499,7 +1499,7 @@
* arguments in a drm_agp_buffer structure.
*/
int drmAgpAlloc(int fd, unsigned long size, unsigned long type,
- unsigned long *address, unsigned long *handle)
+ unsigned long *address, drm_handle_t *handle)
{
drm_agp_buffer_t b;
@@ -1526,7 +1526,7 @@
* This function is a wrapper around the DRM_IOCTL_AGP_FREE ioctl, passing the
* argument in a drm_agp_buffer structure.
*/
-int drmAgpFree(int fd, unsigned long handle)
+int drmAgpFree(int fd, drm_handle_t handle)
{
drm_agp_buffer_t b;
@@ -1550,7 +1550,7 @@
* This function is a wrapper around the DRM_IOCTL_AGP_BIND ioctl, passing the
* argument in a drm_agp_binding structure.
*/
-int drmAgpBind(int fd, unsigned long handle, unsigned long offset)
+int drmAgpBind(int fd, drm_handle_t handle, unsigned long offset)
{
drm_agp_binding_t b;
@@ -1573,7 +1573,7 @@
* This function is a wrapper around the DRM_IOCTL_AGP_UNBIND ioctl, passing
* the argument in a drm_agp_binding structure.
*/
-int drmAgpUnbind(int fd, unsigned long handle)
+int drmAgpUnbind(int fd, drm_handle_t handle)
{
drm_agp_binding_t b;
@@ -1763,7 +1763,7 @@
return i.id_device;
}
-int drmScatterGatherAlloc(int fd, unsigned long size, unsigned long *handle)
+int drmScatterGatherAlloc(int fd, unsigned long size, drm_handle_t *handle)
{
drm_scatter_gather_t sg;
@@ -1775,7 +1775,7 @@
return 0;
}
-int drmScatterGatherFree(int fd, unsigned long handle)
+int drmScatterGatherFree(int fd, drm_handle_t handle)
{
drm_scatter_gather_t sg;
@@ -1942,7 +1942,7 @@
drm_ctx_priv_map_t map;
map.ctx_id = ctx_id;
-map.handle = (void *)handle;
+map.handle = (void *)(unsigned long)handle;
if (ioctl(fd, DRM_IOCTL_SET_SAREA_CTX, map)) return -errno;
return 0;
@@ -1955,7 +1955,7 @@
map.ctx_id = ctx_id;
if (ioctl(fd, DRM_IOCTL_GET_SAREA_CTX, map)) return -errno;
-if (handle) *handle = (drm_handle_t)map.handle;
+if (handle) *handle = (drm_handle_t)(unsigned long)map.handle;
return 0;
}
@@ -1972,7 +1972,7 @@
*size = map.size;
*type = map.type;
*flags = map.flags;
-*handle = (unsigned long)map.handle;
+*handle = (drm_handle_t)(unsigned long)map.handle;
*mtrr = map.mtrr;
return 0;
}
@@ -1995,7 +1995,7 @@
int drmGetStats(int fd, drmStatsT *stats)
{
drm_stats_t s;
-int i;
+unsigned int i;
if (ioctl(fd, DRM_IOCTL_GET_STATS, s)) return -errno;
Index: libdrm/xf86drm.h
===
RCS file: /cvs/dri/drm/libdrm/xf86drm.h,v
retrieving revision 1.6
diff -u -r1.6 xf86drm.h
--- libdrm/xf86drm.h1 Feb 2005 22:09:46 - 1.6
+++ libdrm/xf86drm.h15 Jul 2005 10:30:22 -
@@ -577,11 +577,11 @@
extern int drmAgpEnable(int fd, unsigned long mode);
extern int drmAgpAlloc(int fd, unsigned long size,
unsigned long type, unsigned long *address,
-unsigned long *handle);
-extern int drmAgpFree(int fd, unsigned long handle);
-extern int drmAgpBind(int fd, unsigned long handle,
+drm_handle_t *handle);
+extern int drmAgpFree(int fd, drm_handle_t handle);
+extern int drmAgpBind(int fd, drm_handle_t handle,
unsigned long offset);
-extern int drmAgpUnbind(int fd, unsigned long handle);
+extern int drmAgpUnbind(int fd, drm_handle_t handle);
/* AGP/GART info: authenticated client and/or X */
extern int drmAgpVersionMajor(int fd);
@@ -596,8 +596,8 @@
/* PCI scatter/gather support: X server (root) only */
extern int
Fixes to make DRI Device Info data machine size independent
The Mesa patch below helps to make the data passed between
the Xserver and an DRI client in the GetDeviceInfo request of
the DRI extension independ of the machine size - a prerequisite
to support mixing of 32 and 64bit DRI clients.
The patch eliminates the need to use of drmAddress in these
structures.
drmAddress is unsigned long and therefore machine size dependent.
Furthermore it fixes a bug in the MGA DRI module which makes the
assumption that a 'handle' is a base address of a mapped area.
Appearantly the affected code is not used any more with the latest
versions of DRM.
Like the patches to libdrm none of these fixes should raise any
compatibility issues.
I suggest to postpone the changes which eliminate drmAddress from
these structures and make drm_handle_t unsigned int until all
other things are in place and do them all at once as they will
change the ABI between the Xserver and DRI clients.
Egbert.
Index: src/mesa/drivers/dri/ffb/ffb_xmesa.c
===
RCS file: /cvs/mesa/Mesa/src/mesa/drivers/dri/ffb/ffb_xmesa.c,v
retrieving revision 1.8
diff -u -r1.8 ffb_xmesa.c
--- src/mesa/drivers/dri/ffb/ffb_xmesa.c4 May 2005 20:11:36 -
1.8
+++ src/mesa/drivers/dri/ffb/ffb_xmesa.c15 Jul 2005 09:48:05 -
@@ -61,6 +61,7 @@
{
ffbScreenPrivate *ffbScreen;
FFBDRIPtr gDRIPriv = (FFBDRIPtr) sPriv-pDevPriv;
+ drmAddress map;
if (getenv(LIBGL_FORCE_XSERVER))
return GL_FALSE;
@@ -74,59 +75,59 @@
if (drmMap(sPriv-fd,
gDRIPriv-hFbcRegs,
gDRIPriv-sFbcRegs,
- gDRIPriv-mFbcRegs)) {
+ map)) {
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-regs = (ffb_fbcPtr) gDRIPriv-mFbcRegs;
+ ffbScreen-regs = (ffb_fbcPtr) map;
/* Map ramdac registers. */
if (drmMap(sPriv-fd,
gDRIPriv-hDacRegs,
gDRIPriv-sDacRegs,
- gDRIPriv-mDacRegs)) {
- drmUnmap(gDRIPriv-mFbcRegs, gDRIPriv-sFbcRegs);
+ map)) {
+ drmUnmap((drmAddress)ffbScreen-regs, gDRIPriv-sFbcRegs);
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-dac = (ffb_dacPtr) gDRIPriv-mDacRegs;
+ ffbScreen-dac = (ffb_dacPtr) map;
/* Map Smart framebuffer views. */
if (drmMap(sPriv-fd,
gDRIPriv-hSfb8r,
gDRIPriv-sSfb8r,
- gDRIPriv-mSfb8r)) {
- drmUnmap(gDRIPriv-mFbcRegs, gDRIPriv-sFbcRegs);
- drmUnmap(gDRIPriv-mDacRegs, gDRIPriv-sDacRegs);
+ map)) {
+ drmUnmap((drmAddress)ffbScreen-regs, gDRIPriv-sFbcRegs);
+ drmUnmap((drmAddress)ffbScreen-dac, gDRIPriv-sDacRegs);
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-sfb8r = (volatile char *) gDRIPriv-mSfb8r;
+ ffbScreen-sfb8r = (volatile char *) map;
if (drmMap(sPriv-fd,
gDRIPriv-hSfb32,
gDRIPriv-sSfb32,
- gDRIPriv-mSfb32)) {
- drmUnmap(gDRIPriv-mFbcRegs, gDRIPriv-sFbcRegs);
- drmUnmap(gDRIPriv-mDacRegs, gDRIPriv-sDacRegs);
- drmUnmap(gDRIPriv-mSfb8r, gDRIPriv-sSfb8r);
+ map)) {
+ drmUnmap((drmAddress)ffbScreen-regs, gDRIPriv-sFbcRegs);
+ drmUnmap((drmAddress)ffbScreen-dac, gDRIPriv-sDacRegs);
+ drmUnmap((drmAddress)ffbScreen-sfb8r, gDRIPriv-sSfb8r);
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-sfb32 = (volatile char *) gDRIPriv-mSfb32;
+ ffbScreen-sfb32 = (volatile char *) map;
if (drmMap(sPriv-fd,
gDRIPriv-hSfb64,
gDRIPriv-sSfb64,
- gDRIPriv-mSfb64)) {
- drmUnmap(gDRIPriv-mFbcRegs, gDRIPriv-sFbcRegs);
- drmUnmap(gDRIPriv-mDacRegs, gDRIPriv-sDacRegs);
- drmUnmap(gDRIPriv-mSfb8r, gDRIPriv-sSfb8r);
- drmUnmap(gDRIPriv-mSfb32, gDRIPriv-sSfb32);
+ map)) {
+ drmUnmap((drmAddress)ffbScreen-regs, gDRIPriv-sFbcRegs);
+ drmUnmap((drmAddress)ffbScreen-dac, gDRIPriv-sDacRegs);
+ drmUnmap((drmAddress)ffbScreen-sfb8r, gDRIPriv-sSfb8r);
+ drmUnmap((drmAddress)ffbScreen-sfb32, gDRIPriv-sSfb32);
FREE(ffbScreen);
return GL_FALSE;
}
- ffbScreen-sfb64 = (volatile char *) gDRIPriv-mSfb64;
+ ffbScreen-sfb64 = (volatile char *) map;
ffbScreen-fifo_cache = 0;
ffbScreen-rp_active = 0;
@@ -147,11 +148,11 @@
ffbScreenPrivate *ffbScreen = sPriv-private;
FFBDRIPtr gDRIPriv = (FFBDRIPtr) sPriv-pDevPriv;
- drmUnmap(gDRIPriv-mFbcRegs,
Re: DRM map design
Dave Airlie writes: I've made a patch against the DRM code in CVS adding a few pieces that were missing. The code works for me on both radeon and r128. I've also tried to test mga however the mga code in CVS doesn't seem to work at all right now. My guess would be idr's changes might need some compat work .. no idea though.. I didn't see any problems. mga client side needs two adjustments. One really is a bugfix in code that isn't used with newer versions of DRM and the other one is a fix to the DRIRec structure. We may be able to do some compat work there but I'm not sure if it's worth it. We have already discussed eliminating drmAddress. These changes can be done simultaniously. 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've changed this to use the address value if possible (if it fits into 32bits and if the value has not been used as token for something else). This should help to maintain backward compatibility, on the other hand it may not sufficiently deter people from using handles as base addresses. DRM will work with either version. The kernel does not use drm_handle_t (except for the mga driver) where the use of it has been introduced just recently. I only consider published kernels and released X as stable ABIs so we can change the kernel stuff for the mga now... its in -mm but that is only experimental.. OK, how should we proceed then? I would propose the following: Phase 1: a. Make changes to DRM but leave drm_handle_t unsigned long We could then make texture_handle u32 as this would suffice to hold all significant bits of drm_handle_t although drm_handle_t is still unsigned long. b. convert unsigned long handle to drm_handle_t handle in Mesa and X code. Phase 2: a. change drm_handle_t to unsigned int. b. eliminate drmAddress and make the appropriate changes to driver DRIRec structures in Mesa and X. I can commit all the changes to X. However since some code (the driver DRI files for example) live both in Mesa and X things need to be coordinated somewhat. Can anyone give me a clue how this coordination is done? Cheers, Egbert. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Mesa build problems on non-i386 platform.
I needed the patch below to build Mesa CVS head on x86-64. Otherwise gcc complained about RESTORE_FPU being undefined when compiling t_vb_arbprogram.c Egbert. diff -u -r1.4 t_vb_arbprogram.h --- src/mesa/tnl/t_vb_arbprogram.h 10 Jul 2005 11:23:10 - 1.4 +++ src/mesa/tnl/t_vb_arbprogram.h 13 Jul 2005 13:35:11 - @@ -128,6 +128,7 @@ /*--- */ +#if defined (__i386__) #ifdef NO_FAST_MATH #define RESTORE_FPU (DEFAULT_X86_FPU) #define RND_NEG_FPU (DEFAULT_X86_FPU | 0x400) @@ -135,6 +136,10 @@ #define RESTORE_FPU (FAST_X86_FPU) #define RND_NEG_FPU (FAST_X86_FPU | 0x400) #endif +#else +#define RESTORE_FPU 0 +#define RND_NEG_FPU 0 +#endif /*! * Private storage for the vertex program pipeline stage. --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: ioctl32 on amd64
Alan Hourihane writes: It'd be nice to do something. Using RedHat EL4 the DRM CVS fails to build because the .compat_ioctl doesn't exist in 2.6.9. Or, at the very least, we'll need to check if compat_ioctl exists before allowing compilation. Well, that may be the way to go. The code looks quite different and we need to clutter it with ifdefs since macros don't seem acceptable. Adding a set of separate functions for 2.4 can be left as an exercise to someone who needs it. Egbert. --- 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
Paul Mackerras writes: Keith Whitwell writes: In general I'd prefer that the values passed to clients (and back again) to be abstract tokens rather than actual addresses or offsets into some unspecified address space. Which should mean that 32 bits is more than ample to contain them... The problem that we have is that currently the kernel DRM uses the map-offset field for two different things: (a) as a token for userspace to use to identify a particular map and (b) to store map-type-specific information such as the physical address for _DRM_REGISTERS and _DRM_FRAME_BUFFER maps, or the address within the GART aperture for _DRM_AGP maps, or the kernel virtual address within a scatter/gather mapping for _DRM_SCATTER_GATHER maps. For _DRM_SHM maps, map-offset is set to the kernel virtual address of the memory allocated for the map, but that is only used as a token, not for internal use inside the DRM. In fact it is only by luck that we don't get collisions between the physical addresses used for _DRM_REGISTERS and _DRM_FRAME_BUFFER maps and the kernel virtual addresses used for _DRM_SHM maps at the moment. My patch took the approach of only creating abstract tokens for _DRM_SHM maps, which meant that I didn't need to disentangle (a) and (b). If we are going to create abstract tokens for all maps, we need to do something different. One alternative is to add another field to the kernel's (i.e. the DRM's) version of the drm_map_t, in which to store the userspace token. This is the approach taken by Egbert's patch. The current version of Egbert's patch has the kernel version of the drm_map_t called the same but different from the userspace drm_map_t. I would prefer that the kernel structure be called something different if its contents are different, but that will admittedly make the patch pretty intrusive. That's fine. This can be done, it will just make the patch bigger, which should be less of a concern than future confusion. Another alternative is to have a separate data structure to translate userspace tokens to drm_map_t pointers. The idr structure in the kernel (include/linux/idr.h) is commonly used for this sort of thing. With this approach, we would allocate map handles as small multiples of PAGE_SIZE, and use idr_find(dev-map_idr, handle PAGE_SHIFT) to map from userspace tokens to drm_map_t *'s. I believe we don't ever need to go from drm_map_t * to the userspace token. I'll try to code this up over the weekend so that we can see how intrusive it is likely to be. The advantage is of course that it means we don't have to have different drm_map_t's in the kernel and userspace. Well, both approaches are fine. The disadvantage of the second apporach however is that we have no control over the token value. Therefore we cannot take the gentle approach to make the attempt to leave values that fit into 32bit unchanged. This would definitely change the kernel ABI and may have side effects for some exisiting drivers - especially binary only drivers. Egbert. --- 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: ioctl32 on amd64
Ian Romanick writes: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Egbert Eich wrote: @@ -612,8 +612,7 @@ _tnl_allow_pixel_fog( ctx, GL_FALSE ); _tnl_allow_vertex_fog( ctx, GL_TRUE ); - mmesa-primary_offset = mmesa-mgaScreen-primary.handle; - + mmesa-primary_offset = drmAgpBase(sPriv-fd); ctx-DriverCtx = (void *) mmesa; mmesa-glCtx = ctx; If you look at mgaioctl.c you will find code that does arithmetic with mmesa-primary_offset. In my opinion the assignment: mmesa-primary_offset = mmesa-mgaScreen-primary.handle; is a bug. It is, and in more ways that this. That is why, for MGA DRM = 3.2, this code is no longer used. The only use of the primary handle was to determine when the DMA engine had processed certain command buffers. This case has been replaced by an in-kernel interrupt-based wait mechanism. In the current code, primary_offset is always set to zero if DRM = 3.2. OK, that sounds reasonable. Would the change I've made would still be useful for DRM 3.2? Cheers, Egbert. --- 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: ioctl32 on amd64
Paul Mackerras writes: Haven't I mentined that it does? Handles that fit into 32bit should be handed to userspace unchanged, therefore if there is any code left that does arithmetic with these handles should continue to work. Handles that are used as real bases should be 32bit as these usually are pointer to base addresses. There is still a potential problem with your approach - if we are going to create hashed 32-bit handles for 32-bit processes to use, we have to create the hashed handles even if the addmap is being done by a 64-bit process. The reason is that the X server passes handles to DRI clients. If you have a 64-bit X server which does an addmap and gets a 64-bit handle (which doesn't fit into 32 bits) and that handle is then passed to a 32-bit client, the client won't be able to use it because the 32-bit hashed version of the handle hasn't been created. Exactly. If we want 32 and 64-bit pices to work together we need 32bit handles. If you pass a 64bit handle to a 32-bit client it's useless as mmap() cannot deal with a value in offset that doesn't fit into 32 bit. - at least unless we set -D_FILE_OFFSET_BITS=64. However this may have other undesireable side effects. If we abandon the idea that handles might be real physical addresses then we can use handles that fit into 32 bit Egbert. --- 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: ioctl32 on amd64
Eric Anholt writes: I've taken a look, and started writing down my understanding of handles and offsets here: http://dri.freedesktop.org/wiki/DrmMapHandling Thanks for putting together this page! As far as I could tell, math was not being done on handles. This makes sense, since the DRM mmap handler is comparing whether the passed in offset is exactly equal to (not just in the range of) a map's offset/length. But I'm really concerned about the mixing of handles and Right. However I came across one place where map handles were used as base address of a physical range. Then an offset was added. This had nothing to do with using handles in mmap(). The 'handles' seemed to be some multi purpose thing. Please take a look at https://bugs.freedesktop.org/attachment.cgi?id=2363 and the following change: diff -rNu ../unpatched/Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c --- ../unpatched/Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c 2004-12-16 01:23:47.0 +0100 +++ Mesa/src/mesa/drivers/dri/mga/mga_xmesa.c 2005-04-05 21:26:38.0 +0200 @@ -612,8 +612,7 @@ _tnl_allow_pixel_fog( ctx, GL_FALSE ); _tnl_allow_vertex_fog( ctx, GL_TRUE ); - mmesa-primary_offset = mmesa-mgaScreen-primary.handle; - + mmesa-primary_offset = drmAgpBase(sPriv-fd); ctx-DriverCtx = (void *) mmesa; mmesa-glCtx = ctx; If you look at mgaioctl.c you will find code that does arithmetic with mmesa-primary_offset. In my opinion the assignment: mmesa-primary_offset = mmesa-mgaScreen-primary.handle; is a bug. I've made sure that the kernel code still works even without my changes however there is the small but 0 possibility that it doesn't as this address might have been taken when when squeezing a 64bit address into 32 bit, in which case the HandleID() macro creates a different handle. One could argue that the physical address spaces are usually added before SHMs are so this chance never exists. offsets that I'm seeing, which I really can't reconcile with the code actually working. But if we could confirm that all DRI drivers were using handles to map from, then I think we've got a lot of freedom in deciding what type a handle is. Right. If someone who's looked at this as well could read that page and correct anything I've misunderstood, that would be great. Will do. Egbert. --- 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: ioctl32 on amd64
Paul Mackerras writes: Egbert Eich writes: ... and reinvented the weel repeating the same errors that I have already been thru. What errors do you refer to? Well, I've added a few points to Eric's wiki page. http://dri.freedesktop.org/wiki/DrmMapHandling I would be greatful if we could discuss these issues some more. If we can come to a common understanding of the problems I'd be more than happy to make an implemention for testing. Egbert. --- 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: ioctl32 on amd64
Alan Hourihane writes: There's another issue here. And that's drmAddress in the 2D DDX drivers. On 32bit arches it's 32bits, on 64bit arches it's 64bit. And because drmAddress is passed in the *DRIRec things break. The client-side 3D driver gets the *DRIRec and as it's a different size things are a mess when using a 32bit client on a 64bit arch. It looks like the radeon and r128 don't suffer from this but most of the other drivers do. Yep, the mga driver doesn't suffer from this either. I don't quite see what the purpose of drmAddress is anyway. It looks like it could just as well be replaced by a drm_handle_t as it holds the handle to a map optained by addMap() - at least from what I can tell right now. Egbert. --- 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: ioctl32 on amd64
Paul Mackerras writes: Egbert Eich writes: Exactly. If we want 32 and 64-bit pices to work together we need 32bit handles. If you pass a 64bit handle to a 32-bit client it's useless as mmap() cannot deal with a value in offset that doesn't fit into 32 bit. - at least unless we set -D_FILE_OFFSET_BITS=64. However this may have other undesireable side effects. If we abandon the idea that handles might be real physical addresses then we can use handles that fit into 32 bit My point is that if we are going to use 32-bit handles, we have to convert handles to 32 bits for 64-bit processes as well as 32-bit processes. I don't see your patch doing that. From https://bugs.freedesktop.org/attachment.cgi?id=2691 @@ -285,16 +324,18 @@ list-map = map; down(dev-struct_sem); + map-pub_handle = (map-type == _DRM_SHM + ? HandleID((unsigned long)map-handle,dev) + : HandleID(map-offset,dev)); list_add(list-head, dev-maplist-head); up(dev-struct_sem); This conversion happens in HandleID(). Yes, pub_handle is unsigned long' and thus has the same size as void *handle, but the value it contains is 32bit. For userland the following patch takes care of a lot of cases where an map handle is involved. --- shared/drm.h12 Apr 2005 17:46:45 - 1.1.1.1 +++ shared/drm.h12 Apr 2005 17:48:19 - 1.1.1.2 @@ -126,7 +126,7 @@ #define _DRM_LOCKING_CONTEXT(lock) ((lock) ~(_DRM_LOCK_HELD|_DRM_LOCK_CONT)) -typedef unsigned long drm_handle_t; /** To mapped regions */ +typedef unsigned int drm_handle_t; /** To mapped regions */ typedef unsigned int drm_context_t;/** GLXContext handle */ typedef unsigned int drm_drawable_t; typedef unsigned int drm_magic_t; /** Magic for authentication */ This should take care of all the instances where drm_handle_t is used. In the patches to the Xserver and the dri drivers I had to replace a couple of 'unsigned long' with 'drm_handle_t'. Also Alan came across the problem with drmAddress. This should probably be changed to typedef drm_handle_t drmAddress; Non of the drivers that I looked at used drmAddress, though. I'm not saying that I haven't missed anything. I have tested things with three different drivers and I'm pretty sure I caught everything that matters for these drivers. Egbert. --- 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: ioctl32 on amd64
Alan Hourihane writes: On Thu, Jun 30, 2005 at 03:23:52 +0200, Egbert Eich wrote: Alan Hourihane writes: On Thu, Jun 30, 2005 at 09:46:41AM +0100, Alan Hourihane wrote: For i810 and i830 it can just be removed as it isn't even used. The other drivers just need a little tweaking to remove it's use. How about casting it to drm_handle_t? I think we can just remove it in the other cases. I've just looked at the via and sis drivers and it doesn't make any real use of it. I'm sure the other drivers don't make any real use of it too. I think it's best to just remove it's use completely. Right. Some cleanup doesn't hurt. This drmAddress looks like something that was introduced without checking if something similar existed already. Egbert. --- 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: ioctl32 on amd64
Dave Airlie writes: Looks like that Dave Airlie has pushed another set of patches made by Paul Mackerras into the DRM code. My patches support a wider range of chipsets (Matrox, R128 and Radeon) and provide a framework which makes it easy to add ioctl32 support to more chipsets. Furthermore they have support for both the old style ioctl32 support and the one that uses compat_alloc_user_space() so they should work on a wider range of kernels. And this is probably all fine for DRM CVS or Xorg, but for the kernel it just isn't acceptable, I'd be flamed down if I pushed this patch kernel side, its just a fact of life... I would have to remove all the macros and old style ioctl32 stuff to get this into the kernel, without any way of testing it ... I'm not willing to do that, I'm going to port over the mga and r128 work you've done to Paul's scheme and push them kernel side ... Dave, if you cannot test this why do you want to port my code to Paul's sceme - which seems to be much more error prone than using my sceme? Ripping out the macros is easy to do. There are ifdefs that select between them so the code can easily be identified. All that's left to do will show up immediately when you do a compile. Furthermore if you don't want to do it I would be willing to do that. But I'm not going to remove all the macros as they are there for a reason. Furthermore the DRM code contains a lot of other macros already which have been accepted by the kernel folks. Ripping out the old non-'compat_alloc_userspace()' sceme would tremendously simplify the macros so I'd assume they will look much more acceptable to kernel people. Again, the macros are there to make adding ioctl32 support to other drivers easy. I don't expect people will bother if it's a lot of work, error prone if they don't even have a chance to test it. The changes to types need to clarify what exactly breaks where, I'm not as worried about the interactions between X and Mesa as I am about old Xs and new kernels... if we change the sarea size in X will it run on an old kernel, if I upgrade to a new kernel without changing X will it still work? I'm only taking care of the DRM, really the userspace stuff is going to have to be up to someone with more authority than me... (I've asked for people to review your patch when you first published it, no-one did..) I've investigated this and I did not encounter a situation where anything breaks. I would certainly be able to push the X stuff. However since this is dependent on the DRI bits it should be pushed toegther. I assume there there is a scenario on how to do this, that's been used in the past. Therefore I'm looking for someone who knows how this was done. Maybe Alan can help me on this? Breakage in X- DRI isn't so bad as a release will be consistent.. it'll just break ATI binary drivers... No, it won't - as ATi needs to ship the DRI modules and the X driver together anyhow. Cheers, Egbert. --- 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: ioctl32 on amd64
Paul Mackerras writes: Egbert Eich writes: My patches support a wider range of chipsets (Matrox, R128 and Radeon) and provide a framework which makes it easy to add ioctl32 support to more chipsets. Unfortunately your macros have the effect of increasing the effort required by a kernel developer to read and understand the code. In the kernel we care much more about code being easy to read than about it being easy to write. A kernel developer reading my code sees the function names that they know (access_ok, copy_to_user, etc.) and can see at a glance what the code is doing. Right. This depends on the macros though. The ioctl32 code does the same kind of operation numerous times. The macros make the code less complex and allow the reader to focus on what conversions are done and not on how they are done. It is very unlikely that the macros do the wrong thing once they are set up right. However it's more likely that someone forgets to do a conversion. There are numerous other examples of macros in the DRM code which don't have this nice property. Furthermore they have support for both the old style ioctl32 support and the one that uses compat_alloc_user_space() so they should work on a wider range of kernels. The biggest problem, though, is that you are still using register_ioctl32_conversion, even for your new style support. That function is about to be removed. We need to supply a compat_ioctl function in the file_operations vector, which is what the code which is now upstream does. That's fine. If somone tells me what needs to be done I'm happy to change this. I've been carrying this code along for too long now. When I started this this kind of conversion functions didn't exist. I would also like to discuss the treatment of handles a bit more. You have taken the approach of always hashing handles. I had concluded some time ago that that approach had problems because of the tendency of the DRI userspace to use physical addresses (of the framebuffer and card registers) as the offset in mmap calls (if I remember correctly, it was a while ago that I last looked at this stuff). I'm interested to know how your patch solves that problem. I found one instance of this left in the code. This was in the mga driver and would be easy to fix. In my opinion this is more a bug in the code. Still I've changed the hash function so that it will (most likely) pass values that fit into 32bit unmodified. The problem is that one has to find some number to 'tag' an SHM area. If this number is identical to a physical base address that is added later this physical area needs to receive a different tag. It may be possible to go back to and modify the hash function again a little bit more along the line of what Dave submitted to the kernel if there is consensus that this would make the case where a real physical base has been assigend to an SHM area already and this is not available any more even less likely. Also, does a kernel with your patch work with existing unmodified X servers and DRI clients? On x86_64 that would mean a 64-bit X server with 64-bit clients. Or do you require userspace to be updated if the kernel DRM is updated with your patch? Haven't I mentined that it does? Handles that fit into 32bit should be handed to userspace unchanged, therefore if there is any code left that does arithmetic with these handles should continue to work. Handles that are used as real bases should be 32bit as these usually are pointer to base addresses. Egbert. --- 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: ioctl32 on amd64
Dave Airlie writes: I had been hoping for some more comments from the senior DRI hackers. Egbert's patch takes somewhat the opposite approach from mine; where I extended the RADEONDRIRec structure to have space for 64-bit handles, Egbert's patch unconditionally makes the drm_handle_t be 32-bit. Which is fine if the DRI developers generally agree that limiting handles to 32 bits is OK, but I don't think that discussion has been had yet. Yes a bit of interest from idr, alanh and keithw might help us out here... (and anyone else who knows this area) server and the DRI client is largely separate from the issue of communication between them and the kernel. The one thing that links them is the question of whether handles are always limited to 32 bits or not. Since my area is the DRM and to show why macros were to me not useful I've just checked mga and r128 ports of Egberts code to your framework into DRM CVS, I'd really appreciate someone compile testing them at least (my cross compiler setup is hosed, I'll fix it in the next day or two..), I'd also appreciate if someone could tell me if idr's new mga ioctls need compat code or not ... The key should be to fix them so they don't as long as they are not yet released. Often times it is more a lack of knowledge than necessity that these conversions are needed. Now I've hacked that code together in little over two hours (while watching Raiders of the lost Ark) I don't see the advantage adding all the macros will bring, once you've identified which structs/ioctls need work, a quick editor macro can generate the code nearly... (granted I'm sure there are bugs in what I've just done...) Right. Those bugs have been removed from my code already. Egbert. --- 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: ioctl32 on amd64
Paul Mackerras writes: Egbert Eich writes: Non of the patches that I've posted had problems with backward compatibility. At least not across the kernel/user space interface. Originally I had one that wasn't however that had been fixed before I put patches into the fd.o bugzilla. No, your patches originally changed the size of the drm_map_t, and added a drm32_map_t which was a different size from the old 32-bit So you didn't notice that I've added backward compatibility functions so that the old call would still have worked. Since the size of the structure was different that was easy to do. drm_map_t. That and the fact that I found your patch impossible to follow was why I did my version. ... and reinvented the weel repeating the same errors that I have already been thru. Maybe you should have gotten in touch with me and we could have worked out something. Now you have a kernel drm_map_t which is different from the user drm_map_t. I think this has the potential to be immensely confusing to people. If the kernel needs an internal data structure to keep information about maps, that's fine, but it should have a different name. Fine. I had a different version where I changed the name. Then kernel people told me it was too intrusive since I had to change the name at every occurance. This is why I came up with the drm_pub_map hack. It's really difficult to make it right for everyone in the kernel. Egbert. --- 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: ioctl32 on amd64
Paul Mackerras writes: Dave Airlie writes: The changes to types need to clarify what exactly breaks where, I'm not as worried about the interactions between X and Mesa as I am about old Xs and new kernels... And in context, this comes down to the expectations of existing 64-bit X servers and DRI clients on 64-bit kernels with respect to how map handles and mmap offsets can be generated and used. I know people are currently using 64-bit X servers and DRI clients on x86_64 machines at least. I'm pretty sure that userspace currently expects to be able to use framebuffer and register physical addresses as the offset in an mmap on /dev/dri/card0, and to be able to add an offset to a map handle for an AGP mapping and use that as an offset for mmap. At least the radeon driver does this IIRC. If there was such a case I must have missed it. The only driver where I came across something like this was in the MGA driver. So I made sure that values that fit into 32bit remained unchanged if possible. At the same time I fixed the driver code to obtain the address from some different source - which was entirely possible. Also 64bit offsets that don't fit into 32bit won't do you any good in 32bit as you cannot mmap() them. And you are right, if we make an incompatible change to the user/kernel ABI in the middle of a stable kernel series, people will scream, and rightly so. That's not my plan. Egbert. --- 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: ioctl32 on amd64
Alan Hourihane writes: On Tue, Jan 18, 2005 at 12:45:23AM +, Dave Airlie wrote: Is it possible to run 32bit OpenGL applications on an AMD64 with DRI support? 64bit applications are working fine, but 32bit apps always use software rendering on my machine (Radeon 7500). It looks like an kernel issue. So my question is, if there are any kernel patches available to solve this problem? There is a patch but it doesn't provide full backwards compat .. it's bugzilla 943 on bugs.freedesktopp.org Egbert is hoping to look at it again, I keep getting hopelessly lost in types when I start looking at it.. I don't have the hardware to test it on... Egbert's patch has been updated and it's looking good. I'd suggest committing it to CVS now for more widespread testing. I'll commit it by the end of the week unless there are any arguments against it. Looks like that Dave Airlie has pushed another set of patches made by Paul Mackerras into the DRM code. My patches support a wider range of chipsets (Matrox, R128 and Radeon) and provide a framework which makes it easy to add ioctl32 support to more chipsets. Furthermore they have support for both the old style ioctl32 support and the one that uses compat_alloc_user_space() so they should work on a wider range of kernels. Egbert. --- 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: ioctl32 on amd64
Dave Airlie writes: I've started pushing the kernel bits to the kernel from Paulus, Linus has accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and r128 and whatever other bits are in Egberts patch... I have solved the map-handle issue differently in my code. Also I've support for PCI Gart and SG - which I have not really tested do to lack of HW. And yes, I know the macros seem to be ugly. However they make writing ioctl32 support for new drivers really easy as one doesn't have to understand the macros. They also allow support of older kernels which don't use compat_alloc_userspace(). The fixes to Mesa and Xorg should be taken, the main issue with Egberts patch is it is against Xorg CVS not against the individual components at last look... I'd rather this stuff was fixed in each component separately so finding backwards compatiblity issues will be easier... I've got three different sets: 1. DRM 2. MESA 3. X.Org (the monolithic version, not the modular tree that is just in the making) So I assume that's what you are asking for. I may have done a few tweaks to the Mesa stuff in X.org however I have not even bothered to test this as it will go away soon. Egbert. --- 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: ioctl32 on amd64
Dave Airlie writes: I've started pushing the kernel bits to the kernel from Paulus, Linus has accepted the drm ioc32 and radeon ioc32 stuff, I need to take the MGA and r128 and whatever other bits are in Egberts patch... If this stuff is in the kernel, hasn't it been committed to the DRM CVS ?? Mainly as I've only got two hands, and Paulus submitted it to the kernel first and it was easier to get into -mm and test it... it was a trivial push to get it into Linus's kernel.. also the kernel interfaces for this stuff has changed recently so I'm not sure about how to support older kernels via DRM CVS, so I'd rather punt on that and not support them... It is actually not hard to support both using the macros in my patch. The code that's needed to add ioctl32 support to each driver is identical. Everything is controlled inside the macros. (Theoretically new kernels can support the old method but the new one is much more elegant and reduces the risk of introducing accidental root holes). Egbert. --- 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: ioctl32 on amd64
Dave Airlie writes: I was just a little perplexed (as I'm sure Egbert was too) that the bug #943 hadn't been updated by Paul and all of a sudden it appears in the kernel first without being in the DRM CVS for at least a little while to get tested here. Paul and Egbert discussed it on the bug at the time Paul was working on it .. I was happier with Pauls initial approach for the kernel, and Egberts first patch I also felt to be overly intrusive from the start, and uncaring of backwards compat, i.e. fine for SuSE distros but not for the kernel as we would break old Xs We've discussed the intrusiveness of my patch and I was able to give an explanation on why I did it this way. I'm not sure if all the issues that I had where addressed in Paul's code. Non of the patches that I've posted had problems with backward compatibility. At least not across the kernel/user space interface. Originally I had one that wasn't however that had been fixed before I put patches into the fd.o bugzilla. The original patch did solve the backward compatibility issue in a different way. I've reinvestigated this issue and came up with a simpler solution. I guess we need to pull Paul's Mesa fixes into the Mesa CVS too now ?? Yes they probably do need to be applied alright, really Egberts patch need to take more care of what Paul was aiming for with compatibility... I didn't get enough time to full review his last patch, but I would prefer to see it split up into the drm/Mesa/Xorg pieces so each can be assessed by each team, the days of the drm being a part of Xorg are coming to an end... Dave, that's what I've already done with my latest set. Also compatibility has never been an issue with the patches that I've posted to bugzilla - unless it has been broken accidentally which I would be interested to hear about. That's why I've posted the code for more widespread testing. I was hoping the two of them would sort it out and supply me with a final solution as I've no access to any equipment using this stuff, and couldn't ever get anyone to review Egberts patch until Paul turned up with his own.. Hm. Egbert. --- 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: ioctl32 on amd64
Alan Hourihane writes: On Tue, Jun 28, 2005 at 02:20:44PM +0100, Dave Airlie wrote: I was just a little perplexed (as I'm sure Egbert was too) that the bug #943 hadn't been updated by Paul and all of a sudden it appears in the kernel first without being in the DRM CVS for at least a little while to get tested here. Paul and Egbert discussed it on the bug at the time Paul was working on it .. I was happier with Pauls initial approach for the kernel, and Egberts first patch I also felt to be overly intrusive from the start, and uncaring of backwards compat, i.e. fine for SuSE distros but not for the kernel as we would break old Xs I understand the backwards compatibility issues and that's good to have, but even Paul noted that when the chance arrives that the scheme should be changed to match more of what Egbert was trying to achieve. The libdri.a library has just been bumped to 5.0.0 in X.Org's snapshot 6.8.99.8, so now maybe a good time to adjust things a little more and bump libdrm.a to 2.0.0 as well. I guess we need to pull Paul's Mesa fixes into the Mesa CVS too now ?? Yes they probably do need to be applied alright, really Egberts patch need to take more care of what Paul was aiming for with compatibility... I didn't get enough time to full review his last patch, but I would prefer to see it split up into the drm/Mesa/Xorg pieces so each can be assessed by each team, the days of the drm being a part of Xorg are coming to an end... To be honest, looking at the bug report, I'm not sure which patch should be applied to Mesa and/or X.Org in association with Paul's patch or Egberts. I don't think both sets of patches should be mixed. I was hoping the two of them would sort it out and supply me with a final solution as I've no access to any equipment using this stuff, and couldn't ever get anyone to review Egberts patch until Paul turned up with his own.. Indeed. Things seem to have slid a little here. I hope that Egbert and Paul can hash things out a little more. Yes, I would like to. My patches to drm/X are mainly required to make shared structures identical in size. Paul has added a size converter for the radeon which would provide backward compatibility in user space between the DRI client and the X server. This can be done for some time (if people feel it's necessary) but it's not the solution for the future and should be fixed by adjusting the sizes on either side. I also need to revisit this to see if it takes care of all the places where I found problems. Egbert. --- 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: [Xorg] Damage/Composite + direct rendering clients
Jim Gettys writes: Which is why avoiding server grabs is imporant, as much as possible. It takes a global lock out on the X server and needs to be used with great care. But you cannot rule out that some legacy client apps don't use server grabs for strange purposes. It may in fact be necessary to make some 'priviledged' clients like the composition manager immune to server grabs. Cheers, Egbert. --- 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=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: From Eric Anholt:
Linus Torvalds writes: On Wed, 12 May 2004, Dave Airlie wrote: I just looked at drm.h and nearly all the ioctls use int, this file is included in user-space applications also at the moment, I'm worried changing all ints to __u32 will break some of these, anyone on DRI list care to comment? Right now, all architectures have int being 32-bit, so nothing should break. Apart from sign issues, of course. If there are pointers and long, then those should just not exist. Never expose kernel pointers to user mode (and you really never should pass user pointers back), and long should really just be __u32 instead (since that is what it is on a 32-bit platform - and if it works there, then it should work on a 64-bit platform too). Unfortunately this is done in some places in DRM. Pointers are used as a simple 'handle' to point to areas that are to be mapped by mmap() from user mode. I've done some ioctl32() interfaces for DRM for a few drivers (mga, radeon, r128) to make 32bit software work on 64bit systems such as AMD64. In most cases it was easy to work around the longs as they either did not have to exist at all or could be replaced by something that's platform independent. I have plans to submit these ioctl32() interfaces to Mesa when I get around to do it. Anyway they are unnecessary kludges which should have been avoided from the beginning. Egbert. --- 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=2562alloc_id=6184op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
Sottek, Matthew J writes: Boy, I haven't really been following this too closely, but surely this sort of thing can be resolved with an extension mechanism or api versioning? An extension mechanism is fine for eventually extending the basic functionality, but a driver writer should not have to wait for consensus to add required features to their driver. Currently I don't think we Right. Therefore I would call for an extendable API with driver private parts. There is a basic API to handle a minimal set required to make a dump fb work. Something that can be supported by almost any chip there is. Then augment this with an 'optinal' part which handles stuff that is beyond the basics but well understood and supported by more than one driver. Above this put a driver private API. Stuff in there may over time be merged into the optional part when things are well understood and we can find a common denominator. could get very much consensus on anything other than a very basic API so saying that advanced features can be defined extensions is perhaps too optimistic. If the advanced features can just remain device dependent extensions, at least in the beginning, then we can probably make some actual progress in getting to a design. API versioning is a must no matter what. Right. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Current discussion about the future of free software graphics
sottek writes: Can we wrap this up the discussion and try to get to a consensus on design requirements? I think most of the opinions are starting to solidify enough to start hashing out the requirements and actual design. Also, we probably want to drop the communication down to just one list? I think dri-devel seems to have the widest group of subscribers. Well, I would think there are a lot more people who are interested in this subject than are subscribed on dri-devel. dri-devel really has a different scope. 4: Design must insure that user applications may not set the hardware into an unstable state that could lead to lockup or damage display devices. The 'driver' must do mode validation using data supplied by either the display itself or the application (you need the second as some display devices may not support sending this data or the data sent is bogus). Broken video modes usually result from: 1. broken drivers 2. bogus user level configuration/override Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
David Bronaugh writes: Egbert Eich wrote: I don't think you want to call user mode code from inside the kernel. The kernel could take a passive role and use the mode that a userland program tells it is set. If all the kernel needs is a linear freambuffer of size x * y and depth d there is no problem. Things get a little more complicated if the kernel wants to set the fb start address for scrolling, use acceleration for faster drawing or the framebuffer is not really fully linear. I was talking about the userspace code -only- doing mode setting. It would take the parameters passed to it via a FIFO or whatever, in whatever format, and set that mode on the specified device. Nothing more. It wouldn't have state (if at all possible). One thing I'm not at all sure about is how to have bidirectional communication between kernel and userspace. The idea I had was for the userspace mode-setting program to open a block device-file (like /dev/drmctl0 (just making up names here)) and wait for input in the form of a string (there's no reason to go with the formats I've suggested here; they're just for the sake of argument). On receipt of that input, it would either set the requested mode and tell the kernel exactly what mode it set, or not set the requested mode and tell the kernel it didn't set the mode (both via the same device-file; maybe an ioctl?). That is pretty much like power management is handled today. A user daemon sits there and waits for events. It will act accordingly and return a status to the kernel. But why do you want to do mode setting from inside the kernel anyhow? If we can make the kernel do its output on whatever video mode it gets we should be fine. This way the user app sets the video mode and the kernel can still print emergency messages (well, in theory - as writing to the fb will definitely collide with active accellerator hardware). And the initial mode setting for boot messages needs to happen way earlier - possibly in a bootstrap manager. As I see it, this'd basically get around all the license problems with the mode setting code (it could still be GPL, yet since it isn't in a position to taint, that's OK) and it would result in -one- location, guaranteed, for mode setting code. I don't know whether the one location thing'd be a good idea, but it sounds like one to me. Here my point is that the world is not Linux only (although I use Linux myself) and it would make sense to make this code portable across OSes. In this case GPL may be a problem - especially if the code needs to go into the kernel. The userspace mode-setting program (what I'm talking about here), which would be doing any more tricky mode setting, would have -no- hooks into the kernel. None. Thus, even if it were GPL, it wouldn't be a problem for it to be running on a *BSD. It'd ensure that the mode setting code was -entirely- separate from the X server, any other libraries, etc. It'd also allow the driver writer, at their discretion, to put the code in the kernel (in which case the userspace code would never be used) or in userspace (in which case the kernel would simply request that the userspace code do its bidding). You mean code that could be put either into the kernel or live in userland - depending on the requirements of the underlying OS? Or the requirements of the hardware, or the decisions of the driver creator -- whichever. Of course, the kernel portion would potentially still have license problems... it's not a total solution to that. But -- it does get as much code as you want into userspace, without enforcing policies. Right. Right, however there are people who like to have a more fine grained control over things than just accepting what the driver considers the best-match. Right... what this says to me is that there have to be more possible parameters in this string. And some may even be driver dependent. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Alan Cox writes: In which case bank switch is needed. Its actually not clear you need 2D accel. Its *nice* but not essential. Its becoming more and more the case that console mode is the debug/boot interface for a device. OK. (I'n not talking about VGA banking, but it seems like modern HW may not be able to map in all video memory at the same time). We hit this with the vesa driver - we just use the first 8Mb or so nowdays. That should work. The kernel could use whatever bank is currently mapped. Or the banking is done inside the kernel - as it may be needed anyway to do DRI. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
Alan Cox writes: On Gwe, 2004-05-07 at 21:59, Egbert Eich wrote: However chipset probing/display device probing and mode setting isn't required to live in kernel space. Portability and system stability arguments speak against it. In fact only Apple MAC users seem to advocate this idea to be able to an initial video mode on their systems. Lots of minor systems from mobile phones to supercomputer systems don't have a text mode. That still only requires some predefined mode tables in the kernel in the form of register setting lists - aka the way BIOS tables generally work. Right. On the other hand on lot of systems we need to rely on some firmware to do some basic setup (ie. initialize the graphics chip for memory clock and characteristics of the video memory). I would expect that this firmware can do (or can be told to do) some basic mode set up, too. If there is no such firmware and the initialization needs to be handled e arly during pre-boot process then we are talking about a real custom case anyway. In this case an initial mode would certainly have to be set up along side the low level programming. Wouldn't it be appropriate to leave this to a 'boot loader' whatever this may be in this case - as the boot loader would like to display an initial logo or menu? The kernel could take whatever mode there is (provided it is passed all information it needs) and put its output there - much as it is proposed for the Xserver (Of course the Xserver could not provide meaningful output on a true text mode. Therefore the mode setting API should provide a minimal set of standard features a set of optional features (which may evolve over time) and allow a chipset specific API that may - over time - move into the optional features. The mode setting interface should probably be userspace. How the user space talks to the kernel module behind it is entirely its own business (or even if it does). The mode setting interface itself needs to have a common API above it however. This is how ALSA handles audio and aspects of video4linux2 work. I can see a user space interface which takes the existing XFree86 type mode line structure (timings, hsync +/- etc) being reasonably sane. The X server can compute modes it needs through this, the kernel can use precomputed modes for text and for SAK or can use the same interface via hotplug If we can move mode setting to a library (or a daemon as we may need some persistant data), the Xserver as well as the kernel would be passed information about the mode and would passively make use of it. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
David Bronaugh writes: Egbert Eich wrote: I don't only want to see mode selection in user land but also mode programming. I keep reiterating the reasons: 1. Mode programming for a number of chips needs to be done thru the BIOS. Unless one wants to stick a complete x86 emulator into the kernel this needs to be done from user land. 2. HW programming (especially programming around hw quirks) is a hard job, and you need the hardware - if possible every flavor if it. No need to duplicate this for different OSes - not speaking of the support nightmare that is involved. I don't know if someone else has suggested this (if so, I apologize for stealing your idea, random person), but is there any reason you can't have the more complicated mode programming code (the non-bootstrap variety) as a userspace program which the kernel somehow calls (however it ends up; via FIFO communication, whatever; I'm not a kernel guru), and which does all the mode setting work? I don't think you want to call user mode code from inside the kernel. The kernel could take a passive role and use the mode that a userland program tells it is set. If all the kernel needs is a linear freambuffer of size x * y and depth d there is no problem. Things get a little more complicated if the kernel wants to set the fb start address for scrolling, use acceleration for faster drawing or the framebuffer is not really fully linear. As I see it, this'd basically get around all the license problems with the mode setting code (it could still be GPL, yet since it isn't in a position to taint, that's OK) and it would result in -one- location, guaranteed, for mode setting code. I don't know whether the one location thing'd be a good idea, but it sounds like one to me. Here my point is that the world is not Linux only (although I use Linux myself) and it would make sense to make this code portable across OSes. In this case GPL may be a problem - especially if the code needs to go into the kernel. It'd ensure that the mode setting code was -entirely- separate from the X server, any other libraries, etc. It'd also allow the driver writer, at their discretion, to put the code in the kernel (in which case the userspace code would never be used) or in userspace (in which case the kernel would simply request that the userspace code do its bidding). You mean code that could be put either into the kernel or live in userland - depending on the requirements of the underlying OS? You could simply pass something like this (using an arbitrary text format) to userspace: radeon:1024x768 and have it set the best-match mode. The 'radeon' part, of course, would make sure that the wrong code wasn't used. Likewise, the userspace program could be fed any data it needed this way. Right, however there are people who like to have a more fine grained control over things than just accepting what the driver considers the best-match. Cheers, Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Mesa3d-dev] RE: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl writes: Can you run grub or lilo on these machines? Also, these is no rule saying a device driver can't have several tables of _init register values that can be used to set the mode on a primary monitor at boot. I would just like to see all of the code that does DDC decoding and modeline computations moved to user space. When you add up that code there is about 40K of it in the fbdriver and about 50K in the radeon driver. When the fbdev drivers start probing for multiple heads, TV support, etc that code is going to get even larger. Since the code is used only rarely (in kernel terms) this code should be in user space instead of the driver. I've also proposed that if you really, really want to you could do the DDC probing the in driver at boot and mark all of the code _init. Then the user space code would take over after that. Note that I'm talking about early userspace (initrd) timeframe, not normal user space. Wouldn't it be the job of the kernel bootstrap process to do this initial setup? This bootstrap code would be wiped once the kernel starts up. Allow me to speak up for users of IBM pSeries hardware or Sun SPARC hardware. Users of those systems face exactly the same issues as Mac users. I imagine most embedded systems will be in the same boat. Being forced to use a serial console for early boot messages is so 1980's. ;) The kernel doesn't need to have support for everything, but I think it's important to have at least minimal support. I'm not speaking about a text mode. I would think on most systems the firmware would provide some reasonable initial mode that the kernel can use. If there is no such firmware one would expect there is some preboot software that is used to bootstrap the kernel that could do such a setup - using a number of fixed modes hard coded in tables. (It is a pain to debug, though). Cheers, Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
Sottek, Matthew J writes: I agree. I think we are on the same page. A minimal set of features is all that would be part of the defined mode setting API. It is just a question of if some of the multi-head concepts are generic enough to be part of that defined set. That's exactly the problem. My experience is that many things in mode setting are just too interrelated. You can easily design a very tiny API to set up a mode to get something drawn to the screen, however if you want to make use of all the nice features your hardware offers you will find out that this tiny API is more in your way than it is useful and you'll end up duplicating everything. Regards, Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl writes: --- Egbert Eich [EMAIL PROTECTED] wrote: I fear that we will get a very Linux-centric view on device drivers. This will leave us with device drivers for Linux and a different ones Tell me the right non-Linux lists and I will post there too. There have been significant complaints from the Linux kernel developers over the current DRM code. Most of it centers around the crossplatform support. Better division of the platform specfic code from the generic code should address these. Right. However I've got the impression that this has improved already. As far as DRM is concerned only a few OSes/platforms matter. mode setting and 2D accel is an issue on many more OSes. Many of those don't have a vital community as Linux does. Idnividuals and groups intereseted in X (until now XFree86) on these platforms usually gather on the project related mailing lists. kernel space. One thing that - in my opinion - should *not* live in there is mode detection and initialization. I'm making some progress on this front. I think I've talked benh into it, and he's started talking to Linus about it. If Linux goes this path then is someone going to move the other platforms onto this path too? Support is starting to grow for merging FB/DRM into a simgle driver. --- Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: The proposal is for a user space library that does mode setting as well as other common things like cursor support. This library would in turn load plug-in libraries for each card. Ok, we have been discussing all of these points over and over again, and I will be at KS, so I didn't want to restart the whole thing on this list, but I wanted to note a few things though: For the mode setting case the library would read the DDC data for each head using the existing I2C drivers or the driver plug-in lib for non-standard cases. This data would then be combined with config files where the user can override modelines and such. Most of this exists inside of X already. These pieces could easily be separated out of the server. I agree with the idea of moving the EDID decoding mode selection to userland. In this regard, though, I beleive we should aim toward some I don't only want to see mode selection in user land but also mode programming. I keep reiterating the reasons: 1. Mode programming for a number of chips needs to be done thru the BIOS. Unless one wants to stick a complete x86 emulator into the kernel this needs to be done from user land. 2. HW programming (especially programming around hw quirks) is a hard job, and you need the hardware - if possible every flavor if it. No need to duplicate this for different OSes - not speaking of the support nightmare that is involved. 3. Quality of video driver code is often not what we expect from kernel code. The focus of the developer is often clearly upon getting the hardware to work. Graphics driver programmers shouldn't be forced to have to deal with kernel interfaces. 4. Debugging mode setting code involves a lot of round trips (edit-build- test-edit...). This can be done more effectively from user space. 5. Having this code in user mode in a separate project allows deployment of support for new chipsets. simple library that sits with the kernel, eventually distributed with the kernel tree, to live in initramfs optionally since it may be required to even get a console at boot (which is fine, initramfs is available early). The video cards themselves have PCI drivers that can trigger detection by the library via hotplug, the library could manage things like persistant configuration, either separate desktops or geometry of a complex desktop, etc... and eventually notification of userland clients of mode changes. There are competing requirements here: Libs that wack the hardware should be OS/platform independent as possible. This is also a license issue. Yes, we will most likely need OS dependent non-chipset specific wrappers, but those are cheap to do - a lot cheaper than code dealing directly with chipset quirks. One reason for that is lots of monitors lie about their capabilities in their EDID block, so we want override files. The kernel driver in this case doesn't need to be that much different than the current fbdev's though, except that we want to move the HW access for graphics commands to the kernel too, which basically turns into merging the DRI driver and the fbdev. There is no need, I think, to re-invent the wheel from scratch here, it would be a lot more realistic to build on top of those existing pieces. The modelines would be passed into the plug-in libs which would turn them into register values. Finally the plug-in lib would use a private IOCTL to set the state into the video hardware. It's not that easy. Modelines
Re: [Dri-devel] Redesign of kernel graphics interface
Jon Smirl writes: At the X Developers Conference there was a discussion of the issues around framebuffer and DRI. Theodore Ts'o suggested that I write it up and post it for discussion. I'm going to try and list all of the issues I've heard from all sides so some of the proposed solutions are in conflict. The goal of this list is to provide direction for a topic discussion at the Ottawa Kernel Summit. The top item is that accessing the video hardware is a free for all. There are two device drivers, FB and DRI, plus numerous user space apps, like X and SVGlib, all trying to control the hardware. The result of this is that it is easy to lock up your machine when switching between the different usages. X does particularly nasty things to the hardware from user space without informing the kernel. Here it should be looked at why this is the case. First is a little background that should have been in my original post: http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/000399.html Next is the orginal post: http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/000379.html The reply thread on the kernel summit list is here: http://thunker.thunk.org/pipermail/ksummit-2004-discuss/2004-May/thread.html Some talk about doing a better video memory manager and kgi is here: http://marc.theaimsgroup.com/?l=dri-develr=1b=200405w=2 A major topic that I missed in the original list was how to handle BSD. DRM is under the BSD license and FB is GPL. If these two code bases are merged, what are we going to do about BSD? I don't know the appropriate BSD lists to post this to so please forward as necessary. The problem is bigger than that. There are other OSes that take advantage of the mode initialization code in X. Those people don't have their own mailing lists but exchange informations on those of the X projects. Most of them should be active on the XFree86 lists. Another topic that I missed was, why did kgi fail and what can we do to avoid repeating the same path this time around. After the flames from this settle down I'll try to write a document summarizing the conclusions reached, if any. The best possible outcome would be a design document for review at Kernel Summit. There are many considerations from the XFree86/X.Org Xserver side that people here may only be marginally aware of. After all, these people were those who were involved with some of the issues the most in the past. It would be useful to give those people a chance to state their views, too. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Alan Cox writes: On Iau, 2004-05-06 at 09:39, Egbert Eich wrote: Furthermore I'd argue that as little as necessary should live in the kernel space. One thing that - in my opinion - should *not* live in there is mode detection and initialization. There is a need to handle some mode setup/init in the kernel (think about non-text mode hardware) but the hotplug interface allows most cards to do that in userspace, and all the discussion so far seems keen on that [Kernel folk believe lots should be done in user space too!] Alan, That sounds good! (But we never had problems agreeing on things ;-) ) Whatever code we decide to put into the kernel, we should provide an abstraction layer to not expose the driver writer to arbitrary kernel interfaces. This aids portability, helps to keep things stable and makes this code independent of changes in other parts of the kernel. My experience at least with video driver code is that it is 'expensive' compared to most other software. So people working on such code have a different focus than the rest of the world. Cheers, Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Keith Packard writes: Around 16 o'clock on May 6, Sottek, Matthew J wrote: 1) If the mode setting can be removed from the X server then we can leverage that module for whatever graphics system is required. Some times we need an X server, some times we need something more like a framebuffer. Putting this in one place is a must. 'one place' appears to mean a common library API and not a common kernel API; some cards require extensive code to manage mode selection which can't be effectively implemented in kernel mode (like the current X i810 drivers). Right. There are other reasons that speak for leaving mode setting code out of the kernel: 1. Unlike most other code mode setting is not 'cheap'. Getting this code to work right on all falvors of cards using a specific chip is not an easy task. Keeping this independent of the OS as much as possible removes the need for duplication of this 'blood sweat' code. 2. Mode setting code is often times the result of trial and error trying to tiptoe around undocumented 'features' in the hardware. Although this code often does amazing things its quality is often not very good. It is usually not code one wants to have in the kernel. One may say: this can be fixed! Trust me, experience has show, this doesn't happen! 3. Faster deployment of new chipset support on a wider range of OSes. 2) Providing one place for rendering code would be nice too. For cards which can support it, I'd like to suggest that the GL API seems a natural fit here. Retargeting the X server to GL appears possible, and I hope to have a proof of concept running by OLS to show people. I'm sure this works well when COMPOSITE is enabled and OpenGL is used to accelerate COMPOSITE. I would like to see the performance of COMPOSITE + OpenGL vs. no COMPOSITE + XAA. For other cards, I suggest that there aren't a whole lot of useful accelerated operations; 2D only cards generally don't support general image compositing, so the only critical operations for modern applications are video-video blt and (optionally) solid fill. I've implemented rather a lot of X servers in this way to good effect. With XAA we already have an abstraction model for X that only requires to program the basic hardware dependent functionality in the chipset driver itself and to set bitmask telling the abstraction layer above which functionalities are supported. I'm sure this layer could be generalized. 1) A small, device-independent, API that can be used to set modes and do some very simple rendering. Yes, the lowest level graphics driver needs to be able to request a specific mode and find out how that affects the hardware. I would suggest that the 'mode' selected here be indirect -- a 'symbolic' mode which reflects a more sophisticated configuration as specified by some device-specific mechanism. For instance, it would be nice to start a graphics application in TV mode without that application needing to know about all of the underlying complexities. This is similar to how standard modes are specified in X today -- you request a resolution, which is really just a symbolic name for a list of modes. The driver then selects one of those modes which the monitor can support. This doesn't really work well with 'TV' as this may require a specific resolution that's dependent on the underlying hardware. Your permitted resolutions are often tightly coupled to a lot of hardware dependent parameters. Only the chipset dependent driver can decide which modes it is capable of after it has knowledge about these other parameters. More so, these parameters may change during runtime when for example the output device is to be changed. Therefore any application on top of the driver should be prepared that video mode parameters it cares about (like fb location, fb stride, fb size, resolution, depth (?) may change underneath its feet. 2) A mechanism to make all the device dependent extensions your heart desires. Absolutely -- both for driver writers and mode selection mechanisms. Of course, one thing here is to make sure the kernel API isn't just a 'bag of bits in an ioctl'. Perhaps the kernel API could accept a list of register name/value pairs for the desired mode; the kernel driver would then be responsible for setting the register values appropriately. On some platforms this is already done on the PIO level. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Memory management of AGP and VRAM
Sottek, Matthew J writes: I for one have been waiting to see much of the graphics driver moved to the kernel as well. From a vendor perspective there is quite a lot to be gained. 1) If the mode setting can be removed from the X server then we can leverage that module for whatever graphics system is required. Some times we need an X server, some times we need something more like a framebuffer. Putting this in one place is a must. Moving mode setting from the Xsever does not necessarily mean it has to go into the kernel. 2) Providing one place for rendering code would be nice too. We cannot assume that X is the way to go for all customers. If there were a place to put the device dependent rendering code (kernel module or low level library) then we could write X servers or custom graphics interfaces to use that library. People seem to advocate to utilize OpenGL for 2D rendering on modern chipsets. It remains to be seem how feasable this alternative is. However a solution for this already exists. If we are talking about 3D rendering a solution for this already in the making with standalone MESA. For 2D rendering X has a rather smart infrastructure to map X drawing requests onto those 2D primitives that are commonly provided by chipsets. The driver part there is rather lightweight as most of the work is done by this abstraction layer. It would be great if this interface could be kept for chipsets that need 2D acceleration. 3) Some times you can just do the job easier or better from kernel space. Trapping interrupts instead of polling can save huge amounts of CPU cycles for some usage scenarios. Power management is easier. Sometimes the hardware needs some special memory considerations etc. No need to really harp on any of the details, it is just nice to have the full power of the OS when/if you need it. I think the best way to make everyone happy is to try to achieve two things. I would argue that as little as possible should go into the kernel. There is no question that the resource handling for buses, DMA and irq needs to live within the kernel. The same is true for code that uses DMA. However chipset probing/display device probing and mode setting isn't required to live in kernel space. Portability and system stability arguments speak against it. In fact only Apple MAC users seem to advocate this idea to be able to an initial video mode on their systems. 1) A small, device-independent, API that can be used to set modes and do some very simple rendering. I would suggest get, set, put, copy. Do you suggest to accelerate these and put the acceleration for them into the kernel? This would mean a longer path from user space. Since the these operations typically don't deal with huge areas this may mean a signifficant performance penalty. That would allow the kernel to render consoles or oopsen regardless of the mode (debugging the kernel on top of your X session?), and allow for any API of the month to make use of some very basic functionality. Mode setting should just be small as well, leave all the one-off features for extensions. No need to clutter an API with features that are rare. Although the fbdev is already available, I wouldn't suggest that it is a great platform to build on. The mode setting API is really not very good and it does not have modern concepts of twin, clone etc. I think a clean slate design that didn't try to accomplish everything in device independent manner could be a much more attractive target. Experience has shown that there is almost no way to desing an API so generic that it can effectively deal with new features that come along in the future in an effective way. Soon after XFree86 4 came out graphics cards with what you call twin view became available. We had to kludge around to make this work in XFree86. It was difficult but it was possible because the 4.x driver design was such that the driver was the controlling instance of everything - well, almost everything. All the pieces where this was not entirely true - and the number of heads per chipset was an example here - proved to be nightmares. Therefore the mode setting API should provide a minimal set of standard features a set of optional features (which may evolve over time) and allow a chipset specific API that may - over time - move into the optional features. 2) A mechanism to make all the device dependent extensions your heart desires. Then the X servers, opengl libs, etc can just have a DD component to access the hardware specific API. The more things you try to have a device independent API for, the more problems you will have trying to get agreement. Leave the API's to themselves. We should be trying to create a driver model, not a new graphics API. Ogl, X11, DirectFB, etc should be out of scope. Right. My experience has certainly shown that almost no assumption we have made in the past remained
Re: [Dri-devel] Memory management of AGP and VRAM
Jon Smirl writes: I'm putting together a document for Kernel Summit that describes the issues around graphics device drivers. The kernel developers are currently making first pass comments on it. As soon as I fold their comments in I'll post it to fb-dev, dri-dev and wherever else is appropriate for the next round of comments. Nobody is proposing final solutions yet, I'm just trying to collect everyone's opinion. I fear that we will get a very Linux-centric view on device drivers. This will leave us with device drivers for Linux and a different ones (or none!) for the rest of the world. From an X developers point of view this is a support nightmare as he is the first one users will turn to if things don't work as expected. Furthermore I'd argue that as little as necessary should live in the kernel space. One thing that - in my opinion - should *not* live in there is mode detection and initialization. First of all, we will not be able to do generic VESA mode initialization in the kernel (unless we decide to stick a complete x86 emulator into the kernel). Then many driver developers often take a very naive apporach at things and produce code that I know I don't want to see in my kernel. One can try to educate them which may not always be possible - especailly in the case of closed source drivers. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Memory management of AGP and VRAM
Alex Deucher writes: We also have to consider the trade off between the interfaces a modern graphics driver needs verses maintianing multi-platform availability. If linux merges the FB/DRM drivers and moves certain things to the kernel, there is nothing stopping other OS kernel developers from adding similar features to their kernels, potentially even re-using the linux fb/drm model (pending licenses). If X standardizes on an 1. We are not only supporting OS kernels. And if we do there may exist licenses problems (as you've noted already). Disfranchising these OSes and showing them the finger would be extremely rude. 2. A single code base with thin abstraction wrappers will help to reduce the support burdeon. Requiring to duplicate code in different kernels will introduce different errors on every OS. interface to hardware, we can leave it up to the kernel people to implement that interface. X develpers won't have to worry about re-implementing support for various buses and quirks that the OS already handles. OSes that choose not to support the new interfaces I agree that we should get rid of this crap. When we were finalizing XFree86 4.x I already suggested to move a lot of functionalities that currently exist in the Xserver to the kernel. At this time I was stonewalled by people saying that we will have to be able to support older kernels anyway. Finally I gave up and stuck everything into the Xserver (even duplicating stuff that was already in the newer kernel - because people wanted to use the old cruft) can always fall back on the older releases of X. Future chipsets may not even be useable down the road in the current model. That would be a support nightmare. We still occasionally see bug reports for XFree86 3.x. We probably can dump a lot of the stuff that is currently in the Xserver into an external lib and not worry about it much any more. This lib can be used by everybody who - for whatever reason - doesn't have the kernel interfaces. Egbert. --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] DRM copy VBIOS ROM function
David Dawes writes: On Fri, Nov 07, 2003 at 02:39:49PM -0800, Jon Smirl wrote: I should be more specific, it's mapping the ROM into PCI space that the kernel doesn't know about. Of course the kernel knows about the mapping from PCI space to user space. During a hotplug event the kernel could map the new device on top of the ROM in PCI space. Doesn't it have enough information at the time the PCI space is mapped into user space to know what that PCI space corresponds to, and/or to know that if an area of PCI space has been mapped into user space (and not subsequently unmapped) that it shouldn't be given to a newly inserted device? Also, I think that unmapped PCI ROMs are only mapped in (to PCI and user space) by XFree86 long enough to read their contents, but I'd need to double check that. Yes, this is what happens. It has to be done that way as some cards share address decoders for a MEM and PCI ROM address range. When the PCI ROM Base is not assigned to a same value we either try to find a range (which I would like to leave to the kernel) or use one of the PCI MEM bases which then have to mapped away. Both can lead to problems. If the kernel can provide us with a function that does this, the code for this can be moved to the OS layer with the old code used as fallback for OSes that don't provide this functionality. Egbert. --- This SF.Net email sponsored by: ApacheCon 2003, 16-19 November in Las Vegas. Learn firsthand the latest developments in Apache, PHP, Perl, XML, Java, MySQL, WebDAV, and more! http://www.apachecon.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Linux-fbdev-devel] DRM and pci_driver conversion
Linus Torvalds writes: could lead to problems with hotplug. XFree is also mapping PCI ROMs in without informing the kernel and that can definitely cause problems. Absolutely. Changing PCI configurations without telling the kernel _will_ cause problems. Especially for hotplug systems, but it's also very iffy to do if the card is behind a PCI bridge, since you have to take bridge resources into account (and know which bridges are transparent, which are not, etc etc). Speaking of XFree86: when I developed the PCI resource stuff in XFree86 I was trying to get support from kernel folks to get the appropriate user space interfaces into the kernel. When I got nowhere I decided to do everything myself. XFree86 does PCI bridge tracking and one reason it does this is PCI ROM mapping. The kernel spends a lot of effort on getting this right, and even so it fails every once in a while (devices that use IO or memory regions without announcing them in the standard BAR's are quite common, and the kernel has to have special quirk entries for things like that). Right. One reason why the PCI code in XFree86 looks so difficult is that old ATi Mach?? cards had their 8514 registers (and their mirror images) scattered all over the PIO space. Few enough drivers actually want to enable the roms, but the code should look something like /* Assign space for ROM resource if not already assigned. Ugly. */ if (!pci_resource_start(dev, PCI_ROM_RESOURCE)) if (pci_assign_resource(dev, PCI_ROM_RESOURCE) 0) return -ENOMEM; [Stuff deleted] . Is there any API that allows one to do this from user space? There are plenty of XFree86 drivers around that don't have a DRM kernel module and it should be possible to run those which do without DRI support, therefore it would be a good if the XFree86 driver could do this registration itself. Cheers, Egbert. --- This SF.net email is sponsored by: The SF.net Donation Program. Do you like what SourceForge.net is doing for the Open Source Community? Make a contribution, and help us add new features and functionality. Click here: http://sourceforge.net/donate/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Dri-devel] Adding hardware detection to DRI drivers
Linus Torvalds writes: On Wed, 15 Oct 2003, Michel Dänzer wrote: On Wed, 2003-10-15 at 21:01, Jon Smirl wrote: This new scheme allows the entire PCI probing stage of xfree to be eliminated. I'll believe it when the relevant XFree86 developers agree with you. :) If they don't, they are clueless. There's no way in _hell_ that XFree86 can do as good a job as the kernel, on as wide a variety of hardware. Basically, if the kernel booted far enough that XFree86 is an issue, then the kernel will know how to probe PCI devices. The same is _not_ true of XFree86. I fully agree with you and I wish this had been true at the time I implemented most of the PCI probing code in XFree86. At that time Linux did not provide all information XFree86 required and also relied on the PCI configuration the BIOS performed at POST time. This configuration proved to be wrong in a lot of cases - at least for non active VGA devices. We had to jump thru hoops bending over backwards to 'guess' some information that we could not savely probe. I'm not sure if PCI probing can be eliminated completely from XFree86 as it was suggested in the original posting as it also needs to run with hardware for which no DRI support is available. Furthermore for RAC (Resource Access Control) it needs to know the bus structure (ie which PCI buses live behind a PCI-PCI bridge on which primary bus). All this information however could be retrieved from the kernel. In fact this is done on all platforms except the 'PC-like' ia32 and AMD64 where direct IO access to the configuration space registers is used for performance reasons. On 'sane' OSes which take care of PCI probing and correcting of PCI resources themselves a lot of the PCI validation code could be bypassed. Unfortunately when I suggested this I was told that this code should stay in for all platforms to get much wider testing. I chose to refrain from starting a flamewar Yes, XF86 may need to have some legacy module for backwards compatibility. But thinking that X should try to probe on its own is just silly. There are things like cardbus or compact flash video cards - you need them for external video on things like an iPAQ. I don't think you _really_ want X to know about every single PCI bridge type out there, present and future, and for every architecture out there. For RAC I just would like to know the bus tree (or better to say the PCI-PCI bridges) and I would like to know if devices behind different host bridges or in different domains are in the same address space to know if VGA resources (which a lot of devices still need) may conflict with each other. The information about PCI host bridges was added for some special purposes (like to know if we are allowed to probe for sparsely located 8514 registers). - A question that is rather academical in nature on the platforms where it arises. Egbert. --- This SF.net email is sponsored by OSDN developer relations Here's your chance to show off your extensive product knowledge We want to know what you know. Tell us and you have a chance to win $100 http://www.zoomerang.com/survey.zgi?HRPT1X3RYQNC5V4MLNSV3E54 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: XFree86 merge
Mike A. Harris writes: The problem with the IPv6 support commited to XFree86 CVS, was that it requires the system to have IPv6 support wether you actually use IPv6 at all or not. In other words, if your kernel does not support IPv6, then you can not use XFree86 CVS as it requires IPv6 unconditionally to be available on the system wether or not the X server will actually be used with IPv6. That was the original problem, however I do not know if that is still the case or wether it's been fixed now or not. It's possible that someone fixed the IPv6 to not be unconditional, but if it did get fixed, I must have missed seeing the checkin. No, it shouldn't. I've fixed it. Egbert. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
