Re: [git pull] drm patches for 2.6.27-rc1
On Sat, Oct 18, 2008 at 6:32 PM, Ingo Molnar [EMAIL PROTECTED] wrote: * Keith Packard [EMAIL PROTECTED] wrote: On Sat, 2008-10-18 at 22:37 +0200, Ingo Molnar wrote: But i think the direction of the new GEM code is subtly wrong here, because it tries to manage memory even on 64-bit systems. IMO it should just map the _whole_ graphics aperture (non-cached) and be done with it. There's no faster method at managing pages than the CPU doing a TLB fill from pagetables. Yeah, we're stuck thinking that we can't map the aperture because it's too large, but with a 64-bit kernel, we should be able to keep it mapped permanently. Of course, the io_reserve_pci_resource and io_map_atomic functions could do precisely that, as kmap_atomic does on non-HIGHMEM systems today. okay, so basically what we need is a shared API that does per page kmap_atomic on 32-bit, and just an ioremap() on 64-bit. I had the impression that you were suggesting to extend kmap_atomic() to 64-bit - which would be wrong. Is it possible to use a segment register to map the whole aperture on 32b? A segment register might allow common code on 64b/32b by eliminating the need to move the mapping window around. So, in terms of the 4 APIs you suggest: struct io_mapping *io_reserve_pci_resource(struct pci_dev *dev, int bar, int prot); void io_mapping_free(struct io_mapping *mapping); void *io_map_atomic(struct io_mapping *mapping, unsigned long pfn); void io_unmap_atomic(struct io_mapping *mapping, unsigned long pfn); here is what we'd do on 64-bit: - io_reserve_pci_resource() would just do an ioremap(), and would save the ioremap-ed memory into struct io_mapping. - io_mapping_free() does the iounmap() - io_map_atomic(): just arithmetics, returns mapping-base + pfn - no TLB activities at all. - io_unmap_atomic(): NOP. it's as fast as it gets: zero overhead in essence. Note that it's also shared between all CPUs and there's no aliasing trouble. And we could make it even faster: if you think we could even use 2MB TLBs for the _linear_ ioremap()s here, hm? There's plenty of address space on 64-bit so we can align to 2MB just fine - and aperture sizes are 2MB sized anyway. Or we could go one step further and install these aperture mappings into the _kernel linear_ address space. That would be even faster, because we'd have a constant offset. We have the (2MB mappings aware) mechanism for that already. (Yinghai Cc:-ed - he did a lot of great work to generalize this area.) (In fact if we installed it into the linear kernel address space, and if the aperture is 1GB aligned, we will automatically use gbpages for it. Were Intel to support gbpages in the future ;-) the _real_ remapping in a graphics aperture happens on the GPU level anyway, you manage an in-RAM GPU pagetable that just works like an IOMMU, correct? on 32-bit we'd have what you use in the GEM code today: - io_reserve_pci_resource(): a NOP in essence - io_mapping_free(): a NOP - io_map_atomic(): does a kmap_atomic(pfn) - io_unmap_atomic(): does a kunmap_atomic(pfn) so on 32-bit we have the INVLPG TLB overhead and preemption restrictions - but we knew that. We'd have to allow atomic_kmap() on non-highmem as well but that's fair. Mind sending patches for this? :-) Ingo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Jon Smirl [EMAIL PROTECTED] - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
building and running the Xegl server
I am putting together some documentation for building and running the Xegl server. There are three main pages: http://www.freedesktop.org/wiki/EGL http://www.freedesktop.org/wiki/Xegl http://www.freedesktop.org/wiki/Xegl-run Xegl is not ready for prime time yet. There are still big problems in it's mouse and keyboard drivers that I am going to work on in the next couple of days. It only runs on r200, more will come later. I did try running metacity and all of the apps I could think of. The build process is very complex. It would be valuable if you take notes when first building it and help edit the wiki to make the process more understandable. I've added some notes on running it in a two video card environment, it would be nice if someone who uses a two machine environment could add some comments on how to set that up. There is still a lot of work to do on Xegl. So if you see something that interests you feel free to help out. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] CRTC scanout buffer types
On 8/8/05, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
On Sun, 7 Aug 2005, Jon Smirl wrote:
On 8/7/05, Antonino A. Daplas [EMAIL PROTECTED] wrote:
Vladimir Dergachev wrote:
I agree that something like the above is acceptable, exept that we need
an extra field for offset and another if indexed color or not. So
something like:
A:2/0/R:10/2/G:10/12/B:10/22//I
The offsets are not needed as part of the input, they should be part
of the output display. It is the chip driver that will determine the
offsets, not the user.
So you cannot select between RGB and BGR on hardware that allows to select
that?
If you need that fine of control use the ioctl instead of sysfs.
The only exception I can think of is that the radeon hardware can
control which nibble is used in 4bpp. I'd say if you need that kind of
This is something completely different, since each nibble is a different
pixel.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like
that.
-- Linus Torvalds
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
___
Linux-fbdev-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/linux-fbdev-devel
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] CRTC scanout buffer types
I'm trying to work out a syntax for the sysfs attribute that will control the config. My first idea is to use a alpha/red/blue/green syntax. When red is set and blue/green are missing index mode is set. When green is set and red/blue are missing gray scale is set. Are there chips that can scanout from buffers not packed at a power of two? How should I work different color spaces (YCbCr) into this? 4bpp Index = /4 4bpp greyscale = //4 8bpp Index = /8 8bpp RGB 332 = /3/3/2 8bpp greyscale = //8 16bpp aRGB 1555 = 1/5/5/5 16bpp RGB 565 = /5/6/5 16bpp aRGB = 4/4/4/4 16bpp aIndex 88 = 8/8 24bpp RGB 888 = /8/8/8 24bpp aRGB = 6/6/6/6 32bpp aRGB = 8/8/8/8 32bpp aRGB 2:10:10:10 = 2/10/10/10 How are these packed? 1 bpp monochrome (black = 0 and white = 1 or vice versa) 1 bpp indexed 2 bpp indexed 3 bpp indexed 5 bpp indexed 6 bpp indexed 7 bpp indexed These would have the same config, //8, right? You then just control what you write to the byte. 8 bpp monochrome (black is all zeroes and white is all ones or vice versa) 8 bpp greyscale How does this work, is one 24 bit color the key? 32 bpp indexed+RGB 888 with color key to enable RGB888 -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Linux-fbdev-devel] CRTC scanout buffer types
On 8/7/05, Antonino A. Daplas [EMAIL PROTECTED] wrote: Vladimir Dergachev wrote: I agree that something like the above is acceptable, exept that we need an extra field for offset and another if indexed color or not. So something like: A:2/0/R:10/2/G:10/12/B:10/22//I The offsets are not needed as part of the input, they should be part of the output display. It is the chip driver that will determine the offsets, not the user. The only exception I can think of is that the radeon hardware can control which nibble is used in 4bpp. I'd say if you need that kind of control use the ioctl and keep the sysfs input string simpler. If the config is set from sysfs let the driver pick the nibble order. This also implies that you don't need to control RGB vs BGR on input, just let the driver choose and check what you got on output. This is getting more cryptic by the minute. Can't we have a simple field: value lines ? Something like: AlphaBits: 2 AlphaOffset: 0 The problem with doing that is you need to set everything in one go. Separating all those fields into different sysfs attributes will have a problem with synchronization. One workaround is to have another attribute 'Activate'. Nothing is set until the 'Activate' attribute is written to. There is still the problem of another process changing the other attributes behind the back of the original process. Tony -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CRTC scanout buffer types
On 8/6/05, Patrick McFarland [EMAIL PROTECTED] wrote: On Friday 05 August 2005 04:19 pm, Jon Smirl wrote: I've included the scanout types for the R200, what other ones are supported by the various chips? For example I think the R300 can scanout in floating point. 4bpp Indexed 8bpp Indexed 16bpp aRGB 1555 16bpp RGB 565 24bpp RGB 888 32bpp aRGB 16bpp aRGB 16bpp aIndex 88 32bpp aRGB 2:10:10:10 palette bypassed Note, the r200 supports a lot more buffer formats, but these are the only ones valid for scanout. What does scanout mean? A scanout buffer is a buffer that the graphics chip reads from to directly display on the screen. There are other buffer types like texture and pbuffer that are not directly displayable. For example the Radeon r200 does not allow floating point colors in scanout buffers but they can be used in other buffer types. -- Patrick Diablo-D3 McFarland || [EMAIL PROTECTED] Computer games don't affect kids; I mean if Pac-Man affected us as kids, we'd all be running around in darkened rooms, munching magic pills and listening to repetitive electronic music. -- Kristian Wilson, Nintendo, Inc, 1989 -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
CRTC scanout buffer types
I've included the scanout types for the R200, what other ones are supported by the various chips? For example I think the R300 can scanout in floating point. 4bpp Indexed 8bpp Indexed 16bpp aRGB 1555 16bpp RGB 565 24bpp RGB 888 32bpp aRGB 16bpp aRGB 16bpp aIndex 88 32bpp aRGB 2:10:10:10 palette bypassed Note, the r200 supports a lot more buffer formats, but these are the only ones valid for scanout. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: display lists broken in Mesa maybe due to glapi dispatch changes (?), and an Xthreads problem
This patch worked to make gears display in EGL On 8/3/05, Ian Romanick [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ian Romanick wrote: In addition to my recent commit to Mesa CVS, try this patch. I have verified that everything builds and that glxgears works on a system with current X.org CVS installed. This patch *should* fix everything. :) I built it on a system *without* X.org 7.0rc0 on it, so there may still be build problems on those systems. Dunno. I have also attached the script that I used to test on r200. Run the script as ./mesa_test.sh ~/devel/Mesa-build/lib ~/devel/Mesa-build. The first parameter tells it where to find the DRI drivers (it uses it to set DRI_DRIVERS_PATH) and the second parameter tells it where to find Mesa's progs/demos progs/tests. It assumes that everything is already made in those locations. The only problem I hit was the following assertion in the ARB_vertex_program tests. I don't think that one is my fault, but it could be. r200_swtcl.c:103: r200SetVertexFormat: Assertion `VB-AttribPtr[VERT_ATTRIB_POS] != ((void *)0)' failed. I will try to test on r100, mga, and r128 tonight. I may be able to hit savage as well. If somebody can try i915, unichrome, and tdfx, that would rock. I'm really, really confused as to why this bug doesn't hit X.org CVS builds. The only way that it would not hit is if IN_DRI_DRIVER isn't set. If that's the case, it's also a bug. I'm not sure if we should just apply this patch (should just need the changes to dispatch.h) to X.org CVS or re-import Mesa with the patch applied. Fortunately for me, it's not my call to make. :) I'm going to try and figure out what's going on with the X.org build tomorrow (Thursday). My guess is that IN_DRI_DRIVER isn't included in the defines. As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy about it. The problem is that XlibConf.h contains '#define XTHREADS' to make it easier to build X extensions in the modular build. This used to be set on the command line by imake. My *personal* opinion is that it should be set on the command line by configure. I went ahead and committed this part. 381936c4ef432d131188fe65617ec72b Mesa-200508031610.patch.gz 6242a7bddebf1e823f09802a71db0561 mesa_test.sh -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC8VIoX1gOwKyEAw8RAjvoAJ9ZR5Ok0YV6WOjB9pWNiBUHFcQC+gCfeGMh h50ylD5bloXmpnNF5h2kMAE= =bYu+ -END PGP SIGNATURE- -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] remove need for root to run DRM
This patch removes the need for root to run DRM. It is attached too in
case gmail destroys the formatting.
Major highlights:
1) removal of the general root check on the IOCTLs, added root check in AddMap
1) permanent SAREA map
2) user space can AddMap AGP maps, AGP maps are restricted to creation
in AGP space.
3) Deprecation of some radeon variables now calculated by the driver
I haven't converted PCI GART support. You still need to be root for it to work.
Please look it over and tell me if I have created any security holes.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -280,7 +280,7 @@ typedef int drm_ioctl_compat_t(struct fi
typedef struct drm_ioctl_desc {
drm_ioctl_t *func;
int auth_needed;
- int root_only;
+ int master;
} drm_ioctl_desc_t;
typedef struct drm_devstate {
@@ -375,6 +375,7 @@ typedef struct drm_buf_entry {
/** File private data */
typedef struct drm_file {
int authenticated;
+ int master;
int minor;
pid_t pid;
uid_t uid;
diff --git a/linux-core/drm_bufs.c b/linux-core/drm_bufs.c
--- a/linux-core/drm_bufs.c
+++ b/linux-core/drm_bufs.c
@@ -56,7 +56,8 @@ static drm_local_map_t *drm_find_matchin
list_for_each(list, dev-maplist-head) {
drm_map_list_t *entry = list_entry(list, drm_map_list_t, head);
if (entry-map map-type == entry-map-type
- entry-map-offset == map-offset) {
+ ((entry-map-offset == map-offset) ||
+(map-type == _DRM_SHM))) {
return entry-map;
}
}
@@ -163,6 +164,19 @@ int drm_addmap(drm_device_t * dev, unsig
map-handle = drm_ioremap(map-offset, map-size, dev);
break;
case _DRM_SHM:
+ found_map = drm_find_matching_map(dev, map);
+ if (found_map != NULL) {
+ if (found_map-size != map-size) {
+ DRM_DEBUG(Matching maps of type %d with
+ mismatched sizes, (%ld vs %ld)\n,
+ map-type, map-size, found_map-size);
+ found_map-size = map-size;
+ }
+
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ *map_ptr = found_map;
+ return 0;
+ }
map-handle = vmalloc_32(map-size);
DRM_DEBUG(%lu %d %p\n,
map-size, drm_order(map-size), map-handle);
@@ -181,15 +195,34 @@ int drm_addmap(drm_device_t * dev, unsig
dev-sigdata.lock = dev-lock.hw_lock = map-handle;
/* Pointer to lock */
}
break;
- case _DRM_AGP:
- if (drm_core_has_AGP(dev)) {
+ case _DRM_AGP: {
+ drm_agp_mem_t *entry;
+ int valid = 0;
+
+ if (!drm_core_has_AGP(dev)) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -EINVAL;
+ }
#ifdef __alpha__
- map-offset += dev-hose-mem_space-start;
+ map-offset += dev-hose-mem_space-start;
#endif
- map-offset += dev-agp-base;
- map-mtrr = dev-agp-agp_mtrr; /* for getmap */
+ map-offset += dev-agp-base;
+ map-mtrr = dev-agp-agp_mtrr; /* for getmap */
+
+ for (entry = dev-agp-memory; entry; entry = entry-next) {
+ if ((map-offset = entry-bound)
+ (map-offset + map-offset = entry-bound +
entry-pages *
PAGE_SIZE)) {
+ valid = 1;
+ break;
+ }
+ }
+ if (!valid) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -EPERM;
}
+ DRM_DEBUG(AGP offset = 0x%08lx, size = 0x%08lx\n,
map-offset, map-size);
break;
+ }
case _DRM_SCATTER_GATHER:
if (!dev-sg) {
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
@@ -258,6 +291,9 @@ int drm_addmap_ioctl(struct inode *inode
return -EFAULT;
}
+ if (!(capable(CAP_SYS_ADMIN) || map.type == _DRM_AGP))
+ return -EPERM;
+
err = drm_addmap( dev, map.offset, map.size, map.type, map.flags,
map_ptr );
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -545,13 +545,14 @@ int drm_ioctl(struct inode *inode, struc
if (!func) {
DRM_DEBUG(no function\n);
retcode = -EINVAL;
- } else if ((ioctl-root_only !capable
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote:
@@ -163,6 +164,19 @@ int drm_addmap(drm_device_t * dev, unsig
map-handle = drm_ioremap(map-offset, map-size,
dev);
break;
case _DRM_SHM:
+ found_map = drm_find_matching_map(dev, map);
+ if (found_map != NULL) {
+ if (found_map-size != map-size) {
+ DRM_DEBUG(Matching maps of type %d with
+mismatched sizes, (%ld vs %ld)\n,
+ map-type, map-size, found_map-size);
+ found_map-size = map-size;
+ }
+
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ *map_ptr = found_map;
+ return 0;
+ }
I'm uncomfortable with this matching maps with mismatched sizes code
that now exists in 2 places, and would like to see what the reasoning is
behind it.
Existing Xservers ask for maps that are not the correct size. This
lets them keep working.
diff --git a/shared-core/radeon_cp.c b/shared-core/radeon_cp.c
--- a/shared-core/radeon_cp.c
+++ b/shared-core/radeon_cp.c
@@ -1245,7 +1245,7 @@ static void radeon_set_pciegart(drm_rade
u32 tmp = RADEON_READ_PCIE(dev_priv, RADEON_PCIE_TX_GART_CNTL);
if (on) {
- DRM_DEBUG(programming pcie %08X %08lX %08X\n,
dev_priv-gart_vm_start, dev_priv-bus_pci_gart,dev_priv-gart_size);
+ DRM_DEBUG(programming pcie %08X %08X %08X\n,
dev_priv-gart_vm_start, dev_priv-bus_pci_gart,dev_priv-gart_size);
RADEON_WRITE_PCIE(RADEON_PCIE_TX_DISCARD_RD_ADDR_LO,
dev_priv-gart_vm_start);
RADEON_WRITE_PCIE(RADEON_PCIE_TX_GART_BASE,
dev_priv-bus_pci_gart);
RADEON_WRITE_PCIE(RADEON_PCIE_TX_GART_START_LO,
dev_priv-gart_vm_start);
A dma_addr_t (dev_priv-bus_pci_gart) is a long on at least some
systems. While we may know that it's 32 bits here, a cast will be
needed to avoid warnings.
I was getting a warning in my build.
ioctls where removing the root check introduces privelege escalation for
users with read access to the DRM device (at least):
- DRM_R128_INDIRECT
- DRM_RADEON_INDIRECT
How do we secure these?
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
I forgot to add this in the first patch, you will GPF without it. The
attachment includes it.
@@ -72,7 +80,7 @@ static int drm_setup(drm_device_t * dev)
INIT_LIST_HEAD(dev-ctxlist-head);
dev-vmalist = NULL;
- dev-sigdata.lock = dev-lock.hw_lock = NULL;
+ dev-sigdata.lock = NULL;
init_waitqueue_head(dev-lock.lock_queue);
dev-queue_count = 0;
dev-queue_reserved = 0;
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -280,7 +280,7 @@ typedef int drm_ioctl_compat_t(struct fi
typedef struct drm_ioctl_desc {
drm_ioctl_t *func;
int auth_needed;
- int root_only;
+ int master;
} drm_ioctl_desc_t;
typedef struct drm_devstate {
@@ -375,6 +375,7 @@ typedef struct drm_buf_entry {
/** File private data */
typedef struct drm_file {
int authenticated;
+ int master;
int minor;
pid_t pid;
uid_t uid;
diff --git a/linux-core/drm_bufs.c b/linux-core/drm_bufs.c
--- a/linux-core/drm_bufs.c
+++ b/linux-core/drm_bufs.c
@@ -56,7 +56,8 @@ static drm_local_map_t *drm_find_matchin
list_for_each(list, dev-maplist-head) {
drm_map_list_t *entry = list_entry(list, drm_map_list_t, head);
if (entry-map map-type == entry-map-type
- entry-map-offset == map-offset) {
+ ((entry-map-offset == map-offset) ||
+ (map-type == _DRM_SHM))) {
return entry-map;
}
}
@@ -163,6 +164,19 @@ int drm_addmap(drm_device_t * dev, unsig
map-handle = drm_ioremap(map-offset, map-size, dev);
break;
case _DRM_SHM:
+ found_map = drm_find_matching_map(dev, map);
+ if (found_map != NULL) {
+ if (found_map-size != map-size) {
+DRM_DEBUG(Matching maps of type %d with
+ mismatched sizes, (%ld vs %ld)\n,
+map-type, map-size, found_map-size);
+found_map-size = map-size;
+ }
+
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ *map_ptr = found_map;
+ return 0;
+ }
map-handle = vmalloc_32(map-size);
DRM_DEBUG(%lu %d %p\n,
map-size, drm_order(map-size), map-handle);
@@ -181,15 +195,34 @@ int drm_addmap(drm_device_t * dev, unsig
dev-sigdata.lock = dev-lock.hw_lock = map-handle; /* Pointer to lock */
}
break;
- case _DRM_AGP:
- if (drm_core_has_AGP(dev)) {
+ case _DRM_AGP: {
+ drm_agp_mem_t *entry;
+ int valid = 0;
+
+ if (!drm_core_has_AGP(dev)) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -EINVAL;
+ }
#ifdef __alpha__
- map-offset += dev-hose-mem_space-start;
+ map-offset += dev-hose-mem_space-start;
#endif
- map-offset += dev-agp-base;
- map-mtrr = dev-agp-agp_mtrr; /* for getmap */
+ map-offset += dev-agp-base;
+ map-mtrr = dev-agp-agp_mtrr; /* for getmap */
+
+ for (entry = dev-agp-memory; entry; entry = entry-next) {
+ if ((map-offset = entry-bound)
+ (map-offset + map-offset = entry-bound + entry-pages * PAGE_SIZE)) {
+valid = 1;
+break;
+ }
+ }
+ if (!valid) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -EPERM;
}
+ DRM_DEBUG(AGP offset = 0x%08lx, size = 0x%08lx\n, map-offset, map-size);
break;
+ }
case _DRM_SCATTER_GATHER:
if (!dev-sg) {
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
@@ -258,6 +291,9 @@ int drm_addmap_ioctl(struct inode *inode
return -EFAULT;
}
+ if (!(capable(CAP_SYS_ADMIN) || map.type == _DRM_AGP))
+ return -EPERM;
+
err = drm_addmap( dev, map.offset, map.size, map.type, map.flags,
map_ptr );
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -545,13 +545,14 @@ int drm_ioctl(struct inode *inode, struc
if (!func) {
DRM_DEBUG(no function\n);
retcode = -EINVAL;
- } else if ((ioctl-root_only !capable(CAP_SYS_ADMIN)) ||
- (ioctl-auth_needed !priv-authenticated)) {
+ } else if (((ioctl-master !priv-master) ||
+ (ioctl-auth_needed !priv-authenticated))
+ (!capable(CAP_SYS_ADMIN))) {
retcode = -EACCES;
} else {
retcode = func(inode, filp, cmd, arg);
}
- err_i1:
+err_i1:
atomic_dec(dev-ioctl_count);
if (retcode)
DRM_DEBUG(ret = %x\n, retcode);
diff --git a/linux-core/drm_fops.c b/linux-core/drm_fops.c
--- a/linux-core/drm_fops.c
+++ b/linux-core/drm_fops.c
@@ -34,18 +34,26 @@
* OTHER DEALINGS IN THE SOFTWARE.
*/
-#include drmP.h
#include linux/poll.h
+#include drmP.h
+#include drm_sarea.h
+
static int drm_open_helper(struct inode *inode, struct file *filp, drm_device_t * dev);
static int drm_setup(drm_device_t * dev)
{
+ drm_local_map_t *map;
int i;
if (dev-driver-presetup)
dev-driver-presetup(dev);
+ /* prebuild the SAREA */
+ i = drm_addmap(dev, 0, SAREA_MAX, _DRM_SHM, _DRM_CONTAINS_LOCK, map);
+ if (i != 0)
+ return i;
+
atomic_set(dev-ioctl_count, 0);
atomic_set(dev-vma_count, 0);
dev-buf_use = 0;
@@ -72,7 +80,7 @@ static int drm_setup(drm_device_t * dev)
INIT_LIST_HEAD(dev-ctxlist-head);
dev-vmalist = NULL;
- dev-sigdata.lock = dev-lock.hw_lock = NULL;
+ dev
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote: ioctls where removing the root check introduces privelege escalation for users with read access to the DRM device (at least): - DRM_R128_INDIRECT - DRM_RADEON_INDIRECT How do we secure these? By requiring root. But I didn't review all the ioctls, so these might not be all of the root-requiring ioctls that continue to need it. I thought we built a command verifier to check things like this. Does DRM need to copy, verify, then execute? -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote: On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote: ioctls where removing the root check introduces privelege escalation for users with read access to the DRM device (at least): - DRM_R128_INDIRECT - DRM_RADEON_INDIRECT How do we secure these? By requiring root. But I didn't review all the ioctls, so these might not be all of the root-requiring ioctls that continue to need it. I thought we built a command verifier to check things like this. Does DRM need to copy, verify, then These are the indirect ioctls, which allow the X Server to submit a buffer of any commands it wants. You could probably build a (or extend the current) verifier for the all the things the X Server has done through that ioctl, but that hasn't been done. So there is probably a general security hole here if I can convice the Xserver to use the buffer addresses I want. Who uses these? They aren't used in the mesa tree. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Michel Dänzer [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 15:14 -0400, Jon Smirl wrote: On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote: These are the indirect ioctls, which allow the X Server to submit a buffer of any commands it wants. You could probably build a (or extend the current) verifier for the all the things the X Server has done through that ioctl, but that hasn't been done. So there is probably a general security hole here if I can convice the Xserver to use the buffer addresses I want. That would require a security hole in the X server. The attacker is root already in that case. Who uses these? The current DDX drivers. They aren't used in the mesa tree. So why did you change their requiring root? The version of Xegl I am making does not run as root. It handles multiuser by letting each user run their own instance of Xegl as a normal app. To make this work I have to modify DRM to not need root priv to run. I removed the general root priv check that covered all ioctls. Now we need to review and add it back individually on the ones that need it. For example AddMap was modified to allow mesa to work without root but some of the things X does still need root. The indirect ioctls are not used by mesa. In a little while I'll put together a new patch that adds the root requirement back on those ioctls. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Michel Dänzer [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote: On 8/3/05, Michel Dänzer [EMAIL PROTECTED] wrote: They aren't used in the mesa tree. So why did you change their requiring root? The version of Xegl I am making does not run as root. [...] I know. You missed my question: Why do you change the behaviour of code that doesn't affect what you're trying to achieve? The original code did not separate the concept of auth and root, they were implemented as the same bit. I had to separate the concepts. I kept all of the code implementing auth unchanged. There was a single check looking for root across all IOCTLs. I had to remove that check. Now we have have to identify the IOCTLs that really require root and add the check specifically to them. So far there are only two: addmap and indirect. I could have made three bits: auth_needed, root_only, master. But that was a lot of deltas to implement a root_only bit which is only needed for indirect. Instead it is easier to just add a capability root check in the ioctl. You can't uses a root only bit on addmap since the root requirement is a function of the parameters passed in. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Michel Dänzer [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 15:02 -0400, Jon Smirl wrote: On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 14:39 -0400, Jon Smirl wrote: ioctls where removing the root check introduces privelege escalation for users with read access to the DRM device (at least): - DRM_R128_INDIRECT - DRM_RADEON_INDIRECT How do we secure these? By requiring root. But I didn't review all the ioctls, so these might not be all of the root-requiring ioctls that continue to need it. I thought we built a command verifier to check things like this. These ioctls are designed for privileged clients like the current DDX drivers and thus unchecked. Ok, that's not inconsistent with what I am trying to do. I can just add a root capability check on those two IOCTLs. From IRC see I see that they are only used by the Xserver internally. Mesa doesn't need them. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
New version that protects r128 and radeon IOCTLs with root capablity
check. Please review this patch. We need everyone's eyes to make sure
there are no accidental security holes.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -280,7 +280,7 @@ typedef int drm_ioctl_compat_t(struct fi
typedef struct drm_ioctl_desc {
drm_ioctl_t *func;
int auth_needed;
- int root_only;
+ int master;
} drm_ioctl_desc_t;
typedef struct drm_devstate {
@@ -375,6 +375,7 @@ typedef struct drm_buf_entry {
/** File private data */
typedef struct drm_file {
int authenticated;
+ int master;
int minor;
pid_t pid;
uid_t uid;
diff --git a/linux-core/drm_bufs.c b/linux-core/drm_bufs.c
--- a/linux-core/drm_bufs.c
+++ b/linux-core/drm_bufs.c
@@ -56,7 +56,8 @@ static drm_local_map_t *drm_find_matchin
list_for_each(list, dev-maplist-head) {
drm_map_list_t *entry = list_entry(list, drm_map_list_t, head);
if (entry-map map-type == entry-map-type
- entry-map-offset == map-offset) {
+ ((entry-map-offset == map-offset) ||
+(map-type == _DRM_SHM))) {
return entry-map;
}
}
@@ -163,6 +164,19 @@ int drm_addmap(drm_device_t * dev, unsig
map-handle = drm_ioremap(map-offset, map-size, dev);
break;
case _DRM_SHM:
+ found_map = drm_find_matching_map(dev, map);
+ if (found_map != NULL) {
+ if (found_map-size != map-size) {
+ DRM_DEBUG(Matching maps of type %d with
+ mismatched sizes, (%ld vs %ld)\n,
+ map-type, map-size, found_map-size);
+ found_map-size = map-size;
+ }
+
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ *map_ptr = found_map;
+ return 0;
+ }
map-handle = vmalloc_32(map-size);
DRM_DEBUG(%lu %d %p\n,
map-size, drm_order(map-size), map-handle);
@@ -181,15 +195,34 @@ int drm_addmap(drm_device_t * dev, unsig
dev-sigdata.lock = dev-lock.hw_lock = map-handle;
/* Pointer to lock */
}
break;
- case _DRM_AGP:
- if (drm_core_has_AGP(dev)) {
+ case _DRM_AGP: {
+ drm_agp_mem_t *entry;
+ int valid = 0;
+
+ if (!drm_core_has_AGP(dev)) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -EINVAL;
+ }
#ifdef __alpha__
- map-offset += dev-hose-mem_space-start;
+ map-offset += dev-hose-mem_space-start;
#endif
- map-offset += dev-agp-base;
- map-mtrr = dev-agp-agp_mtrr; /* for getmap */
+ map-offset += dev-agp-base;
+ map-mtrr = dev-agp-agp_mtrr; /* for getmap */
+
+ for (entry = dev-agp-memory; entry; entry = entry-next) {
+ if ((map-offset = entry-bound)
+ (map-offset + map-offset = entry-bound +
entry-pages *
PAGE_SIZE)) {
+ valid = 1;
+ break;
+ }
+ }
+ if (!valid) {
+ drm_free(map, sizeof(*map), DRM_MEM_MAPS);
+ return -EPERM;
}
+ DRM_DEBUG(AGP offset = 0x%08lx, size = 0x%08lx\n,
map-offset, map-size);
break;
+ }
case _DRM_SCATTER_GATHER:
if (!dev-sg) {
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
@@ -258,6 +291,9 @@ int drm_addmap_ioctl(struct inode *inode
return -EFAULT;
}
+ if (!(capable(CAP_SYS_ADMIN) || map.type == _DRM_AGP))
+ return -EPERM;
+
err = drm_addmap( dev, map.offset, map.size, map.type, map.flags,
map_ptr );
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -545,13 +545,14 @@ int drm_ioctl(struct inode *inode, struc
if (!func) {
DRM_DEBUG(no function\n);
retcode = -EINVAL;
- } else if ((ioctl-root_only !capable(CAP_SYS_ADMIN)) ||
- (ioctl-auth_needed !priv-authenticated)) {
+ } else if (((ioctl-master !priv-master) ||
+ (ioctl-auth_needed !priv-authenticated))
+ (!capable(CAP_SYS_ADMIN))) {
retcode = -EACCES;
} else {
retcode = func(inode, filp, cmd, arg
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Eric Anholt [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 17:10 -0400, Jon Smirl wrote: On 8/3/05, Michel Dänzer [EMAIL PROTECTED] wrote: On Wed, 2005-08-03 at 16:18 -0400, Jon Smirl wrote: On 8/3/05, Michel Dänzer [EMAIL PROTECTED] wrote: They aren't used in the mesa tree. So why did you change their requiring root? The version of Xegl I am making does not run as root. [...] I know. You missed my question: Why do you change the behaviour of code that doesn't affect what you're trying to achieve? The original code did not separate the concept of auth and root, they were implemented as the same bit. I had to separate the concepts. I kept all of the code implementing auth unchanged. There was a single check looking for root across all IOCTLs. I had to remove that check. Now we have have to identify the IOCTLs that really require root and add the check specifically to them. So far there are only two: addmap and indirect. I could have made three bits: auth_needed, root_only, master. But that was a lot of deltas to implement a root_only bit which is only needed for indirect. Instead it is easier to just add a capability root check in the ioctl. In your previous patch you removed the root check entirely, even though that lead to vulnerabilities. I pointed out two cases, but I didn't review all the ioctls. Before a patch based on this goes in, I would like a review of every previously root-requiring ioctl to explain why it's okay to not require root on it now. I have been asking on this list for a month now for everyone to help locate where there are vulnerabilities with dropping root priv. Multiple people have told me that AddMap was the only problem. You just pointed out another one with radeon/r128 indirect. Alternatively, you could do what Michel suggested: make only the changes that are required for your nonroot case, so that the security implications are (relatively) obvious. Mesa hits every main DRM entry point. I believe the problem is now with the drivers. Are there other X only driver entry points? It is more reliable if you can just tell me what are the likely problem areas than it is for me to go grepping around xorg trying to figure out what it uses. Any ioctl that is X only can be set to require root priv. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
Here are the main IOCTLs that used to require root. Now they are restricted to the first process that opens the DRM device. Of couse that process may not be an Xserver. Can people add notes about possible security problems with each of these? DRM_IOCTL_IRQ_BUSID DRM_IOCTL_SET_VERSION DRM_IOCTL_SET_UNIQUE DRM_IOCTL_BLOCK DRM_IOCTL_UNBLOCK DRM_IOCTL_AUTH_MAGIC DRM_IOCTL_ADD_MAP - still does in most cases DRM_IOCTL_SET_SAREA_CTX DRM_IOCTL_ADD_CTX DRM_IOCTL_RM_CTX DRM_IOCTL_MOD_CTX DRM_IOCTL_SWITCH_CTX DRM_IOCTL_NEW_CTX DRM_IOCTL_ADD_DRAW DRM_IOCTL_RM_DRAW DRM_IOCTL_ADD_BUFS DRM_IOCTL_MARK_BUFS DRM_IOCTL_CONTROL DRM_IOCTL_AGP_ACQUIRE DRM_IOCTL_AGP_RELEASE DRM_IOCTL_AGP_ENABLE DRM_IOCTL_AGP_ALLOC DRM_IOCTL_AGP_FREE DRM_IOCTL_AGP_BIND DRM_IOCTL_AGP_UNBIND DRM_IOCTL_SG_ALLOC DRM_IOCTL_SG_FREE -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Dave Airlie [EMAIL PROTECTED] wrote: restricted to the first process that opens the DRM device. Of couse that process may not be an Xserver. Can people add notes about possible security problems with each of these? You've missed all the driver ioctls.. please make a list of current driver ioctls that need root as well.. I was saving them until we went through the base ones first. I'm not over-the-moon about this approach of changing the system to be default allow anything and adding root checks, I'd rather it was default root check and overrideable to allow non-root... I started off that way but then I figured out that very few ioctl need to require root. That would require adding about 70 root checks and then turning around and eliminating most of them immediately since mesa uses almost all of the ioctls (indirect is the only exception I know of) We can get the same effect just by inspecting the list of ioctls. Dave. -- David Airlie, Software Engineer http://www.skynet.ie/~airlied / airlied at skynet.ie Linux kernel - DRI, VAX / pam_smb / ILUG --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
On 8/3/05, Ian Romanick [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Smirl wrote: On 8/3/05, Dave Airlie [EMAIL PROTECTED] wrote: I'm not over-the-moon about this approach of changing the system to be default allow anything and adding root checks, I'd rather it was default root check and overrideable to allow non-root... I started off that way but then I figured out that very few ioctl need to require root. That would require adding about 70 root checks and then turning around and eliminating most of them immediately since mesa uses almost all of the ioctls (indirect is the only exception I know of) We can get the same effect just by inspecting the list of ioctls. The difference being that you can incrementally remove root-checks without compromising the system. The same cannot be said for incrementally adding them. Alright I will add them, but I am not convinced we will learn anything about where the vulnerabilities are. But it will have the effect of leaving the non-radeon drivers as root only until they are converted for EGL use. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFC8WfyX1gOwKyEAw8RAsl8AJ9BpLonnpNTdETFS/C5zmHAxr/9gwCcD0wa mab3pazwkd13LCmYcDgFAUM= =C9NI -END PGP SIGNATURE- -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] remove need for root to run DRM
Root IOCTLs used by my first test program.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drm_drv.c b/linux-core/drm_drv.c
--- a/linux-core/drm_drv.c
+++ b/linux-core/drm_drv.c
@@ -65,36 +65,36 @@ drm_ioctl_desc_t drm_ioctls[] = {
[DRM_IOCTL_NR(DRM_IOCTL_GET_MAP)] = {drm_getmap, 0, 0, 0},
[DRM_IOCTL_NR(DRM_IOCTL_GET_CLIENT)] = {drm_getclient, 0, 0, 0},
[DRM_IOCTL_NR(DRM_IOCTL_GET_STATS)] = {drm_getstats, 0, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_SET_VERSION)] = {drm_setversion, 0, 1, 0},
[DRM_IOCTL_NR(DRM_IOCTL_SET_UNIQUE)] = {drm_setunique, 1, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_BLOCK)] = {drm_noop, 1, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_UNBLOCK)] = {drm_noop, 1, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_AUTH_MAGIC)] = {drm_authmagic, 1, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_ADD_MAP)] = {drm_addmap_ioctl, 1, 1, 0},
[DRM_IOCTL_NR(DRM_IOCTL_RM_MAP)] = {drm_rmmap_ioctl, 1, 0, 0},
[DRM_IOCTL_NR(DRM_IOCTL_SET_SAREA_CTX)] = {drm_setsareactx, 1, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_GET_SAREA_CTX)] = {drm_getsareactx, 1, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)] = {drm_addctx, 1, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)] = {drm_rmctx, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_ADD_CTX)] = {drm_addctx, 1, 1, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_RM_CTX)] = {drm_rmctx, 1, 1, 0},
[DRM_IOCTL_NR(DRM_IOCTL_MOD_CTX)] = {drm_modctx, 1, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_GET_CTX)] = {drm_getctx, 1, 0, 0},
[DRM_IOCTL_NR(DRM_IOCTL_SWITCH_CTX)] = {drm_switchctx, 1, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_NEW_CTX)] = {drm_newctx, 1, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_RES_CTX)] = {drm_resctx, 1, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)] = {drm_adddraw, 1, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)] = {drm_rmdraw, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_ADD_DRAW)] = {drm_adddraw, 1, 1, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_RM_DRAW)] = {drm_rmdraw, 1, 1, 0},
[DRM_IOCTL_NR(DRM_IOCTL_LOCK)] = {drm_lock, 1, 0, 0},
[DRM_IOCTL_NR(DRM_IOCTL_UNLOCK)] = {drm_unlock, 1, 0, 0},
[DRM_IOCTL_NR(DRM_IOCTL_FINISH)] = {drm_noop, 1, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_ADD_BUFS)] = {drm_addbufs, 1, 1, 0},
[DRM_IOCTL_NR(DRM_IOCTL_MARK_BUFS)] = {drm_markbufs, 1, 1, 1},
[DRM_IOCTL_NR(DRM_IOCTL_INFO_BUFS)] = {drm_infobufs, 1, 0, 0},
[DRM_IOCTL_NR(DRM_IOCTL_MAP_BUFS)] = {drm_mapbufs, 1, 0, 0},
@@ -102,17 +102,17 @@ drm_ioctl_desc_t drm_ioctls[] = {
/* The DRM_IOCTL_DMA ioctl should be defined by the driver. */
[DRM_IOCTL_NR(DRM_IOCTL_DMA)] = {NULL, 1, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_CONTROL)] = {drm_control, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_CONTROL)] = {drm_control, 1, 1, 0},
#if __OS_HAS_AGP
- [DRM_IOCTL_NR(DRM_IOCTL_AGP_ACQUIRE)] = {drm_agp_acquire_ioctl, 1, 1,
1},
- [DRM_IOCTL_NR(DRM_IOCTL_AGP_RELEASE)] = {drm_agp_release_ioctl, 1, 1,
1},
- [DRM_IOCTL_NR(DRM_IOCTL_AGP_ENABLE)] = {drm_agp_enable_ioctl, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_AGP_ACQUIRE)] = {drm_agp_acquire_ioctl, 1, 1,
0},
+ [DRM_IOCTL_NR(DRM_IOCTL_AGP_RELEASE)] = {drm_agp_release_ioctl, 1, 1,
0},
+ [DRM_IOCTL_NR(DRM_IOCTL_AGP_ENABLE)] = {drm_agp_enable_ioctl, 1, 1, 0},
[DRM_IOCTL_NR(DRM_IOCTL_AGP_INFO)] = {drm_agp_info_ioctl, 1, 0, 0},
- [DRM_IOCTL_NR(DRM_IOCTL_AGP_ALLOC)] = {drm_agp_alloc, 1, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_AGP_FREE)] = {drm_agp_free, 1, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_AGP_BIND)] = {drm_agp_bind, 1, 1, 1},
- [DRM_IOCTL_NR(DRM_IOCTL_AGP_UNBIND)] = {drm_agp_unbind, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_IOCTL_AGP_ALLOC)] = {drm_agp_alloc, 1, 1, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_AGP_FREE)] = {drm_agp_free, 1, 1, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_AGP_BIND)] = {drm_agp_bind, 1, 1, 0},
+ [DRM_IOCTL_NR(DRM_IOCTL_AGP_UNBIND)] = {drm_agp_unbind, 1, 1, 0},
#endif
[DRM_IOCTL_NR(DRM_IOCTL_SG_ALLOC)] = {drm_sg_alloc, 1, 1, 1},
diff --git a/shared-core/radeon_state.c b/shared-core/radeon_state.c
--- a/shared-core/radeon_state.c
+++ b/shared-core/radeon_state.c
@@ -3056,9 +3056,9 @@ void radeon_driver_free_filp_priv(drm_de
}
drm_ioctl_desc_t radeon_ioctls[] = {
- [DRM_IOCTL_NR(DRM_RADEON_CP_INIT)] = {radeon_cp_init, 1, 1, 1},
- [DRM_IOCTL_NR(DRM_RADEON_CP_START)] = {radeon_cp_start, 1, 1, 1},
- [DRM_IOCTL_NR(DRM_RADEON_CP_STOP)] = {radeon_cp_stop, 1, 1, 1},
+ [DRM_IOCTL_NR(DRM_RADEON_CP_INIT)] = {radeon_cp_init, 1, 1, 0},
+ [DRM_IOCTL_NR(DRM_RADEON_CP_START)] = {radeon_cp_start, 1, 1, 0},
+ [DRM_IOCTL_NR(DRM_RADEON_CP_STOP)] = {radeon_cp_stop, 1, 1, 0},
[DRM_IOCTL_NR(DRM_RADEON_CP_RESET)] = {radeon_cp_reset, 1, 1, 1
Re: display lists broken in Mesa maybe due to glapi dispatch changes (?), and an Xthreads problem
I think I'm hitting the display list problem in EGL too. I can't get eglgears to draw but other apps do. On 8/1/05, Ian Romanick [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In addition to my recent commit to Mesa CVS, try this patch. I have verified that everything builds and that glxgears works on a system with current X.org CVS installed. The problem with display lists was really, really stupid. The changes to dispatch.h existed when I tested everything. However, I had added them by hand. Shortly before committing, I regenerated the file. Since the script did not contain the changes, they were lost when the file was regenerated. D'oh! I'm really, really confused as to why this bug doesn't hit X.org CVS builds. The only way that it would not hit is if IN_DRI_DRIVER isn't set. If that's the case, it's also a bug. I'm not sure if we should just apply this patch (should just need the changes to dispatch.h) to X.org CVS or re-import Mesa with the patch applied. Fortunately for me, it's not my call to make. :) As for the s/XTHREADS/USE_XTHREADS/ change, I'm not terribly happy about it. The problem is that XlibConf.h contains '#define XTHREADS' to make it easier to build X extensions in the modular build. This used to be set on the command line by imake. My *personal* opinion is that it should be set on the command line by configure. 7ddbfb1ad2cbd6b3c3e61e7128f906b6 Mesa-200508011040.patch -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD4DBQFC7mEQX1gOwKyEAw8RAlMdAKCZe3qcw61nVEw9mLfS4TCMxjGeRACY1aen 2yT61/LyAUhN7ivtLfhdjQ== =x6eQ -END PGP SIGNATURE- ___ xorg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xorg -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
New OpenGL/ES spec for shader support
http://www.khronos.org/news/press/releases/rel45.html -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Radeon scanout buffer types
Do any of the radeon chips support RGB10 or RGB10_A2 for their scanout buffers? If so, do these chips have 10 bit color maps? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon scanout buffer types
On 7/28/05, Alex Deucher [EMAIL PROTECTED] wrote: On 7/28/05, Jon Smirl [EMAIL PROTECTED] wrote: Do any of the radeon chips support RGB10 or RGB10_A2 for their scanout buffers? If so, do these chips have 10 bit color maps? newer radeons (r300+, IIRC) have 10 bit CLUTs. So they can scan out RGB10 and RGB10_A2, right? Alex -- Jon Smirl [EMAIL PROTECTED] -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
more GLX clean up
On 7/12/05, Brian Paul [EMAIL PROTECTED] wrote: So GLX_BUILT_IN_XMESA is old? I just did a 'make World' and it didn't appear in the logs. GLX_BUILT_IN_XMESA is old stuff and should probably be removed. The idea was for libGL to fall back to stand-alone Mesa Xlib rendering if the X server didn't support the GLX extension. That was important for some of the distros years ago. Do you want to get rid of GLX_BUILT_IN_XMESA since you're cleaning everything up? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI_NEW_INTERFACE_ONLY
There are still some uses of this in the DRI tree... [EMAIL PROTECTED] mesa-cg]$ grep -r DRI_NEW_INTERFACE_ONLY * configs/freebsd-dri:DEFINES = -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 configs/linux-solo: -DDRI_NEW_INTERFACE_ONLY -DPTHREADS -DUSE_EXTERNAL_DXTN_LIB=1 -DDRM_USE_MALLOC configs/linux-solo-ia64:DEFINES = -DDRI_NEW_INTERFACE_ONLY -D_POSIX_SOURCE -D_SVID_SOURCE -D_BSD_SOURCE -D_POSIX_C_SOURCE=199309L -D_GNU_SOURCE -DDRM_USE_MALLOC include/GL/internal/dri_interface.h:#ifndef DRI_NEW_INTERFACE_ONLY -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Left over in dri_interface.h
/** * \name Functions provided by the driver loader. */ /[EMAIL PROTECTED]/ extern __DRIscreen *__glXFindDRIScreen(__DRInativeDisplay *dpy, int scrn); -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
EGL on radeon DRI
Is anyone interested in working on this while I'm at OLS next week? I have it all compiling and sort of working, but things are still not initialized totally right. Something is still messed up when setting up the DRM driver. I'll make up some diffs if anyone is interested. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Reworking GLX/dri_util for EGL
Is this method better than reworking dri_util.c? I still had to
replace some XF86DRIxxx calls in dri_util.c. There needs to be some
way to replace the __glxXX calls in the dispatch table. Right now I'm
using an #ifdef but it can't stay that way.
Both schemes have merit. I probably like the first scheme of doing the
glx_find_dri_screen() call before you get into dri_util. Then change
things like driCreateNewContext to take __DRIscreen* instead of
Display/scrn.
My EGL porgram run on DRI now but I'm not getting any drawing output.
I must still have something messed up in the buffer
pointers/stride/whatever.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/src/glx/x11/glxcmds.c b/src/glx/x11/glxcmds.c
--- a/src/glx/x11/glxcmds.c
+++ b/src/glx/x11/glxcmds.c
@@ -72,6 +72,26 @@ static void * DriverCreateContextWrapper
Display *dpy, XVisualInfo *vis, void *shared, __DRIcontext *ctx,
const __GLcontextModes *fbconfig, int render_type );
+GLboolean __glXCreateContextWithConfig(__DRInativeDisplay* dpy, int screen,
+int configID, void* context, drm_context_t * hHWContext);
+
+GLboolean __glXCreateDrawable( __DRInativeDisplay * ndpy, int screen,
+__DRIid drawable, drm_drawable_t * hHWDrawable );
+
+GLboolean __glXDestroyDrawable( __DRInativeDisplay * ndpy, int screen,
+__DRIid drawable );
+
+GLboolean __glXDestroyContext( __DRInativeDisplay * ndpy, int screen,
+__DRIid drawable );
+
+GLboolean __glXGetDrawableInfo(__DRInativeDisplay * ndpy, int screen,
__DRIid drawable,
+unsigned int* index, unsigned int* stamp,
+int* X, int* Y, int* W, int* H,
+int* numClipRects, drm_clip_rect_t ** pClipRects,
+int* backX, int* backY,
+int* numBackClipRects, drm_clip_rect_t ** pBackClipRects );
+
+
#ifndef DRI_NEW_INTERFACE_ONLY
static Bool dummyBindContext2( Display *dpy, int scrn,
GLXDrawable draw, GLXDrawable read, GLXContext gc );
@@ -2926,8 +2946,11 @@ static const struct name_address_pair GL
GLX_FUNCTION( __glXFindDRIScreen ),
GLX_FUNCTION( __glXGetInternalVersion ),
GLX_FUNCTION( __glXWindowExists ),
- GLX_FUNCTION2( __glXCreateContextWithConfig,
XF86DRICreateContextWithConfig ),
- GLX_FUNCTION2( __glXGetDrawableInfo, XF86DRIGetDrawableInfo ),
+ GLX_FUNCTION( __glXCreateContextWithConfig ),
+ GLX_FUNCTION( __glXCreateDrawable ),
+ GLX_FUNCTION( __glXDestroyDrawable ),
+ GLX_FUNCTION( __glXDestroyContext ),
+ GLX_FUNCTION( __glXGetDrawableInfo ),
/*** DRI configuration ***/
GLX_FUNCTION( glXGetScreenDriver ),
@@ -3057,7 +3080,7 @@ int __glXGetInternalVersion(void)
}
-
+#ifndef EGL_DRI
static Bool windowExistsFlag;
static int windowExistsErrorHandler(Display *dpy, XErrorEvent *xerr)
@@ -3067,7 +3090,7 @@ static int windowExistsErrorHandler(Disp
}
return 0;
}
-
+#endif
/**
* Determine if a window associated with a \c GLXDrawable exists on the
* X-server. This function is not used internally by libGL. It is provided
@@ -3087,6 +3110,12 @@ static int windowExistsErrorHandler(Disp
*
* \since Internal API version 20021128.
*/
+#ifdef EGL_DRI
+static Bool __glXWindowExists(Display *dpy, GLXDrawable draw)
+{
+ return GL_TRUE;
+}
+#else
static Bool __glXWindowExists(Display *dpy, GLXDrawable draw)
{
XWindowAttributes xwa;
@@ -3099,7 +3128,7 @@ static Bool __glXWindowExists(Display *d
XSetErrorHandler(oldXErrorHandler);
return windowExistsFlag;
}
-
+#endif
/**
* Get the unadjusted system time (UST). Currently, the UST is measured in
diff --git a/src/glx/x11/glxext.c b/src/glx/x11/glxext.c
--- a/src/glx/x11/glxext.c
+++ b/src/glx/x11/glxext.c
@@ -65,6 +65,9 @@
#include sys/mman.h
#include xf86dri.h
#include sarea.h
+#ifdef EGL_DRI
+#include egldri.h
+#endif
#include dri_glx.h
#endif
@@ -1508,17 +1511,61 @@ GLXDrawable glXGetCurrentDrawable(void)
//
#ifdef GLX_DIRECT_RENDERING
+#ifdef EGL_DRI
/* Return the DRI per screen structure */
-__DRIscreen *__glXFindDRIScreen(__DRInativeDisplay *dpy, int scrn)
+__DRIscreen *__glXFindDRIScreen(__DRInativeDisplay *ndpy, int scrn)
+{
+ driDisplay *disp = (driDisplay *)ndpy;
+ return disp-driScreen;
+}
+GLboolean __glXCreateContextWithConfig(__DRInativeDisplay* ndpy, int
screen, int configID, void* context, drm_context_t * hHWContext)
+{
+ return GL_TRUE;
+}
+GLboolean __glXCreateDrawable( __DRInativeDisplay * ndpy, int screen,
__DRIid drawable, drm_drawable_t * hHWDrawable )
+{
+ return GL_TRUE;
+}
+GLboolean __glXDestroyDrawable( __DRInativeDisplay * ndpy, int
screen, __DRIid drawable )
+{
+ return GL_TRUE;
+}
+GLboolean __glXDestroyContext( __DRInativeDisplay * ndpy, int screen,
__DRIid context )
+{
+ return GL_TRUE;
+}
+GLboolean __glXGetDrawableInfo(__DRInativeDisplay * ndpy, int screen,
__DRIid drawable,
+unsigned int* index, unsigned int* stamp,
+int* X, int* Y, int* W, int* H,
+int* numClipRects, drm_clip_rect_t ** pClipRects,
+int
Build DRI exactly like X needs
Is there a way to build DRI exactly like X needs from the mesa tree or can this only be done instead the X tree? If I made the right set of stubs could I build in the mesa tree? Do I need to define GLX_BUILT_IN_XMESA? -- Jon Smirl [EMAIL PROTECTED] --- 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: Build DRI exactly like X needs
On 7/12/05, Adam Jackson [EMAIL PROTECTED] wrote: On Tuesday 12 July 2005 10:03, Jon Smirl wrote: Is there a way to build DRI exactly like X needs from the mesa tree or can this only be done instead the X tree? If I made the right set of stubs could I build in the mesa tree? Do I need to define GLX_BUILT_IN_XMESA? Huh? How is 'make linux-dri' insufficient? If I follow all of the make files it looks like linux-dri is using a glx from the mesa tree instead of the one from xorg. That's what GLX_BUILT_IN_XMESA controls. The imake files turn it on: lib/GL/glx/Imakefile: XMESA_DEFINES = -DGLX_BUILT_IN_XMESA lib/GL/mesa/drivers/x11/Imakefile: XMESA_DEFINES = -DGLX_BUILT_IN_XMESA -- Jon Smirl [EMAIL PROTECTED] --- 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: Build DRI exactly like X needs
On 7/12/05, Adam Jackson [EMAIL PROTECTED] wrote: On Tuesday 12 July 2005 11:17, Jon Smirl wrote: On 7/12/05, Adam Jackson [EMAIL PROTECTED] wrote: On Tuesday 12 July 2005 10:03, Jon Smirl wrote: Is there a way to build DRI exactly like X needs from the mesa tree or can this only be done instead the X tree? If I made the right set of stubs could I build in the mesa tree? Do I need to define GLX_BUILT_IN_XMESA? Huh? How is 'make linux-dri' insufficient? If I follow all of the make files it looks like linux-dri is using a glx from the mesa tree instead of the one from xorg. That's what GLX_BUILT_IN_XMESA controls. The imake files turn it on: lib/GL/glx/Imakefile: XMESA_DEFINES = -DGLX_BUILT_IN_XMESA lib/GL/mesa/drivers/x11/Imakefile: XMESA_DEFINES = -DGLX_BUILT_IN_XMESA The glx from the Mesa tree is the GLX client side library. It used to live in xc; now it doesn't. src/glx/x11 is the canonical location for the GLX client library. It is, in other words, exactly what X needs. So GLX_BUILT_IN_XMESA is old? I just did a 'make World' and it didn't appear in the logs. This is the new one, GLX_USE_MESA? -- Jon Smirl [EMAIL PROTECTED] --- 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
libGL and GLX
So if I am reading the code right X's GLX implementation is inside of libGL. So how do I do an alternative GLX implementation? miniglx just built another libGL. I could do that too but is there a better way? -- Jon Smirl [EMAIL PROTECTED] --- 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: libdrm 1.0
There are still copies of structs/defines in xf86drm.h that are
duplicates of ones in drm.h with with underscore appended. This is
confusing since the first thing xf86drm.h does is include drm.h. I
would like to remove the duplicates in xf86drm.h. This is a great way
to cause bugs if people don't know about the duplicate defines.
Things like this:
typedef enum {
DRM_FRAME_BUFFER= 0, /** WC, no caching, no core dump */
DRM_REGISTERS = 1, /** no caching, no core dump */
DRM_SHM = 2, /** shared, cached */
DRM_AGP = 3, /** AGP/GART */
DRM_SCATTER_GATHER = 4, /** PCI scatter/gather */
DRM_CONSISTENT = 5 /** PCI consistent */
} drmMapType;
typedef enum drm_map_type {
_DRM_FRAME_BUFFER = 0,/** WC (no caching), no core dump */
_DRM_REGISTERS = 1, /** no caching, no core dump */
_DRM_SHM = 2, /** shared, cached */
_DRM_AGP = 3, /** AGP/GART */
_DRM_SCATTER_GATHER = 4, /** Scatter/gather memory for PCI DMA */
_DRM_CONSISTENT = 5 /** Consistent memory for PCI DMA */
} drm_map_type_t;
--
Jon Smirl
[EMAIL PROTECTED]
---
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
display vs screen structures
If I run X on a system with one two headed card and one single head card, which structure does X build? display0 - two head card screen0 - head1 screen1 - head2 display1 - single head card screen0 - head1 -- display screen0 - 2: head1 screen1 - 2: head2 screen2 - 1:head1 -- display screen0 - two head card head0 head1 screen1 -single head card head 0 In the current DRI code contexts are associated with screens. How would this work for a card that has no visible screens and is a compute only render device? In my EGL code contexts are associated with the card, not the screen. This is causing me problems when I try using DRI which associates them with screens. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DMA bitblt pageing?
http://lwn.net/Kernel/LDD3/ Chapter 15 explains how DMA works under Linux. -- Jon Smirl [EMAIL PROTECTED] --- 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
DRI library and assumptions about GLX
In several places the DRI code is assuming that it is implementing
GLX. One example of this is __glXFindDRIScreen.
All of the context functions take (__DRInativeDisplay *dpy, int scrn)
and then call pDRIScreen = glx_find_dri_screen(dpy, scrn); to get the
screen object. The assumption here is that screens are int's, in my
case they are not.
I also have two sets of mapping going on; at the higher level it is
GLX screens and lower level it is EGL screens. There is only one
mapping function.
Another way to do this would be to create something like
struct {
__DRIscreen screen;
} GLXScreen;
The context functions would then take pointers to GLXScreen and the
find_dri_screen would take place before calling the DRI code. Only
screens have this problem, other objects are ok.
DRI calls these GLX functions:
__glXCreateContextModes
__glXCreateContextWithConfig
__glXFindDRIScreen
__glXGetDrawableInfo
__glXGetInternalVersion
__glXGetUST
__glXScrEnableExtension
__glXWindowExists
glXGetMscRateOML
It also makes calls to these XF86DRI functions:
XF86DRICreateContext
XF86DRICreateDrawable
XF86DRIDestroyDrawable
XF86DRIDestroyContext
XF86DRIQueryDirectRenderingCapable
XF86DRIOpenConnection
XF86DRIAuthConnection
XF86DRIGetClientDriverName
XF86DRIQueryVersion
XF86DRIGetDeviceInfo
XF86DRICloseConnection
XF86DRIGetDrawableInfo
Is there any simple way to sort of this out? I'd rather not build
another version of dri_util.c with slight variations just to support
EGL.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
Any ideas on what to call my DRM sysfs attribute which provides the name of the corresponding DRI library? I named it dri initially but that may not be descriptive enough. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote: Shouldn't this just be a string you pull right out of a drm ioctl? I know the name currently lives in the server, but as with many things the server does I think that's a mistake. Binding EGL driver load to sysfs is not portable. The code is only in my Linux drivers. In your EGL app you specify something like :0. The generic code is wired to always load dri_egl.so for the :? syntax. dri_egl then figures out which screen corresponds to :0 and looks for the DRM sysfs entry. It then uses that to load the right DRI driver and passes control over. On Linux sysfs attributes and ioctls are very similar. It is now preferred on Linux to get simple things like this from a sysfs attribute instead of an ioctl since the sysfs attributes avoid 32/64 and endian issues. It is also easy for a human to see which driver the DRM module needs. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On 7/3/05, Jon Smirl [EMAIL PROTECTED] wrote: Any ideas on what to call my DRM sysfs attribute which provides the name of the corresponding DRI library? I named it dri initially but that may not be descriptive enough. I called it dri_library_name, we can always change it. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On 7/3/05, Adam Jackson [EMAIL PROTECTED] wrote: Why aren't the DRI drivers themselves EGL drivers? That's sort of the model I was anticipating: - eglChooseDisplayMESA(display/0) - EGL translates to /dev/dri/card0, opens it - ioctl: what's the DRI driver name for this device? - kernel: i915 - EGL loads i915_dri.so, calls its egl setup - eglCreateContext notices the attached dri driver, does device setup I guess I don't see the point of loading one module to have it load another, particularly if that first module is always getting loaded. Brian wants to keep libEGL crossplatform and generic so this forces me into a third library. I'm putting all of the common code into the third library too. It contains code similar to miniglx.c -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRI vs DRM
On 7/3/05, Brian Paul [EMAIL PROTECTED] wrote: I said I'd like to keep the src/egl/main/ directory cross-platform. The Linux version of libEGL.so could certainly have additional code in it. But I'm certainly open to ideas. I just don't have much time to spend on this project. The code is in a separate library currently but it is not hard to merge it into the Linux version of libEGL. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
On 7/3/05, Paul Mackerras [EMAIL PROTECTED] wrote:
Jon Smirl writes:
drmMap never cares about the handle since drmMap turns into mmap and
mmap doesn't know about DRM maps.
Huh? drm_mmap certainly does know about DRM maps.
I see now that drmMap is overriding mmap's offset to pass in the
handle. So the reason my code is working is that the DRM handle and
offset are currently the same number.
int drmMap(int fd,
drm_handle_t handle,
drmSize size,
drmAddressPtr address)
{
static unsigned long pagesize_mask = 0;
if (fd 0) return -EINVAL;
if (!pagesize_mask)
pagesize_mask = getpagesize() - 1;
size = (size + pagesize_mask) ~pagesize_mask;
*address = mmap(0, size, PROT_READ|PROT_WRITE, MAP_SHARED, fd, handle);
if (*address == MAP_FAILED) return -errno;
return 0;
}
I had switched to using offset since sarea had a handle of zero. A
handle of zero doesn't work because it trips this code at the
beginning of drm_mmap.
int drm_mmap(struct file *filp, struct vm_area_struct *vma)
{
DRM_DEBUG(start = 0x%lx, end = 0x%lx, offset = 0x%lx\n,
vma-vm_start, vma-vm_end, VM_OFFSET(vma));
if (!priv-authenticated)
return -EACCES;
/* We check for dma. On Apple's UniNorth, it's valid to have
* the AGP mapped at physical address 0
* --BenH.
*/
if (!VM_OFFSET(vma)
#if __OS_HAS_AGP
(!dev-agp
|| dev-agp-agp_info.device-vendor != PCI_VENDOR_ID_APPLE)
#endif
)
return drm_mmap_dma(filp, vma);
When I passed in sarea's handle I was ending up in drm_mmap_dma.
The trouble with using the offset returned by drmGetMap is that if
your program is a 32-bit program running on a 64-bit kernel, and the
kernel map-offset value for the map you want is 4G, then your
32-bit program will only see the bottom 32 bits of the offset value,
and you end up with no way for your 32-bit program to mmap the map.
That's why I am suggesting that the kernel should create a 32-bit
token for each map and return it in the handle field, and the program
should use that as the mmap offset when mmapping the map.
I'm fine with switching to true handles. I'm not really sure what the
check for 'dma' is looking for. But we need to fix sarea to have a
proper handle.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
DRI vs DRM
Is this table right? DRMDRI ffb ffb i810i830 i830i830 i915i915 mach64 mach64 mgamga r128r128 radeonradeon or r200 or r300 savagesavage sis sis tdfx tdfx via unichome nonefb There are three DRI drivers with no DRM. What is up with these? gamma s3v trident During the EGL driver load process it checks /sys/drm/* looking for card? entries. When it finds one I need a sysfs attribute in /sys/drm/card?/dri to tell me which dri library to load. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
Don't the maps always contain the physical address of the object? That would provide a unique handle. Where does the handle get used in user space? After I GetMap() to find the map I need, I pass the offset back into drmMap() not the handle. Offset is the physical address in most cases. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] r300 driver locks up with Xglx
On 7/1/05, Nicolai Haehnle [EMAIL PROTECTED] wrote: If it's a bug on our (i.e. the driver's) side, we should fix it, whether or not Xglx itself is in a usable state. It's likely that Xglx hits code paths that aren't used by most programs. Xglx is working pretty well. I'd suggest using it as a test case for your r300 work. It exercises a large number of OpenGL features some of which are not comonly used. It is also a good thing to compare to since it works without problems on the ATI drivers. http://www.freedesktop.org/wiki/Software_2fXgl -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
I've attached my current diffs to DRM. I am coverting DRM so that the
server does not have to run as root. The attached code allows this.
Most of the changes are in AddMap.
1) sarea is prebuilt
2) agp maps are allowed from non-root master but checked to make sure
they are within allocated agp space.
3) I haven't done PCI maps yet they will look like the AGP ones.
I will probaby get rid of the changes where I added an extra parameter
to the IOCTL macros before check in.
From user space I use loops like this:
for (i = 0;; i++) {
if (drmGetMap(disp-drmFD, i, offset, size, type, flags,
handle, mtrr) != 0)
break;
if (type == DRM_SHM) {
if (drmMap( disp-drmFD, offset, size,
(drmAddressPtr)(disp-pSAREA)) 0) {
fprintf(stderr, [drm] drmMap failed\n);
return 0;
}
break;
}
}
if (!disp-pSAREA)
return 0;
drmMap never cares about the handle since drmMap turns into mmap and
mmap doesn't know about DRM maps.
--
Jon Smirl
[EMAIL PROTECTED]
patch
Description: Binary data
Re: DRM map design
On 6/29/05, Thomas Hellström [EMAIL PROTECTED] wrote: Currently the drivers are AddMap'ing multiple little maps over the AGP area, but the area is basically split into two area: private for the master and public for the DRI clients to write to. So to get around the root priv requirement of AddMap I could have DRM initially create a map which only allows master access to AGP space. Then the non-root master could safely AddMap sub-maps which must exist inside of the predefined AGP map. These sub-maps would lower the priv requirements for parts of AGP space and allow the clients to run. The via drm module needs a kernel 2MB _RESTRICTED AGP map for the command stream. The master must not have access to that part, since it will allow a non-root master to modify the command stream once it has been security-checked. How will drmAgpAlloc be handled? I mean, how will DRM know how big the initial map will be? drmAgpAlloc() allocs drm_agp_mem structures which track the agp allocs. I could change the map system to allow a single map to be paired with each struct drm_agp_mem. The 2MB restricted you are using was allocated with a call to drmAgpAlloc(), right? You would then add a _RESTRICTED map which would bind to the struct drm_agp_mem and stop further maps. We need to a check to make sure a normal user can't free and reallocate a piece of AGP memory marked restricted. The drivers would then be changed to alloc the various parts of AGP space instead of allocing one big chunk and carving it up. By allocing multiple pieces the master can set different privs on each piece. Backwards compatibility is maintained since root can make any maps that it wants ignoring the one map per struct drm_agp_mem restriction. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
On 6/29/05, Paul Mackerras [EMAIL PROTECTED] wrote: Do either of you (or does anyone) have a good mental grasp of how map handles and offsets are used and manipulated in the X server and in DRI clients? In particular, I'm interested to know under what circumstances map handles are generated by arithmetic on other map handles, or obtained from a source other than a DRM_IOCTL_ADD_MAP ioctl. Similarly for the offset in a mmap on /dev/dri/cardN; do we do arithmetic to get those values? The underlying question is to what extent the handle returned by DRM_IOCTL_ADD_MAP needs to be predictable (or have a predictable relationship to other handles) rather than just being an arbitrary token invented by the kernel DRM code. I don't think that map handles are being computed in any uniform way. Sometimes they are zero, sometimes the physical address, sometime the kernel virtual address. I'm not clear on what user space is supposed to do with handles. I'm doing drmGet(), getting the offset and then passing the offset back into drmMap(). I just ran into a problem where the handle for the framebuffer was zero and that won't work with drmMap(). After changing to the offset field I am just ignoring the handles. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
On 6/29/05, Jon Smirl [EMAIL PROTECTED] wrote: drmAgpAlloc() allocs drm_agp_mem structures which track the agp allocs. I could change the map system to allow a single map to be paired with each struct drm_agp_mem. The 2MB restricted you are using was allocated with a call to drmAgpAlloc(), right? You would then add a _RESTRICTED map which would bind to the struct drm_agp_mem and stop further maps. We need to a check to make sure a normal user can't free and reallocate a piece of AGP memory marked restricted. The drivers would then be changed to alloc the various parts of AGP space instead of allocing one big chunk and carving it up. By allocing multiple pieces the master can set different privs on each piece. Backwards compatibility is maintained since root can make any maps that it wants ignoring the one map per struct drm_agp_mem restriction. A better scheme to do this might be to leave drmAddMap alone and create a new DRM entry point drmAgpAllocMap(). drmAddMap() would continue to be root only. drmAgpAllocMap() is derived from drmAgpAlloc() but also builds a map entry spanning the agp space allocated. It takes an additional parameter for the appropriate DRM_MAP flags. drmAgpAllocMap() would be marked master-only, not root-only. I believe this would be a better approach than changing drmAddMap to allow some maps to be added without root priv and others still needing it. drmAgpAllocMap() already has all of the info it needs, it is easy for it to make the map too. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Bug in i810 agp support?
In i810/server/i810_dri.c there is a call to agp alloc without the type set to zero: drmAgpAlloc(ctx-drmFD, 4096 * 1024, 1, NULL, dcacheHandle); A type of one translates into U16_APER_SIZE which doesn't match the request size of 4MB. Is this a bug or do I not understand the type parameter on agp alloc? This is the only place where a type other than zero is used. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Bug in i810 agp support?
On 6/29/05, Keith Whitwell [EMAIL PROTECTED] wrote: Jon Smirl wrote: In i810/server/i810_dri.c there is a call to agp alloc without the type set to zero: drmAgpAlloc(ctx-drmFD, 4096 * 1024, 1, NULL, dcacheHandle); A type of one translates into U16_APER_SIZE which doesn't match the request size of 4MB. Is this a bug or do I not understand the type parameter on agp alloc? This is the only place where a type other than zero is used. The i810 had an optional bank of dedicated video ram, the dcache, which was useful for certain tasks despite having lower bandwidth than regular shared/system ram. This memory required special handling - I would say the type parameter would have been added for this case in particular. Note that this is not the same as the i810's stolen ram which is allocated off the top of regular memory at boot time by the bios. If I am reading the code right the type ends up straight in the kernel's agp_allocate_memory(pages, type); Then looking at the kernel code the type goes into the chip agp driver and then comes back out later. I can't find any documentation on what 'type' does. I don't have any reason to think it's not working, it was just odd that it was the only non-zero use in the system. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On 6/28/05, Alan Hourihane [EMAIL PROTECTED] wrote: O.k. I've yanked the code from CVS for this now, as I don't want to pollute things if they're not going to work properly. Is anyone working on a stub driver ?? While you wait on the great stub debate to be settled (it has been going on for about 18 months with no action) why not simply fix intelfb to work right on the i915? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 915 DRM PM
On 6/27/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: You could be a pioneer and write the first stub driver. I've looked at the problem and you need about 80% of the fbdev code in the stub. I just didn't think it was worth the engineering effort to split 20 existing fbdev drivers. Since I didn't want to split the drivers I was just using them as the stub. Ugh ? 80% ? How did you get that figure ? I'd say less than 10% :) Unless you count the radeon PM stuff in the stub ... Depends on what is in the bottom layer. Is mode support there so that we can set a mode at boot? DDC probe? Common functions for start/stop the GPU, vesafb users should shift to the board specific fb drivers if available. If the board specific fb driver isn't working we should simply fix it instead of building and entire architecture to avoid it's use. It's always good to have a fallback solution Right now suspend resume are handled in the fbdev drivers. I don't think it would work in the case of vesafb and DRM. From what I can tell vesafb use is pretty rare. A while ago I broke things in DRM CVS so that vesafb wouldn't work, it was about two months until we got a complaint. DRM CVS is fixed for vesafb but the long lag indicates that there aren't very many users. After the problem the user switched to radeonfb. Sure we should keep vesafb around but it won't have all of the features of the board specific fbdev driver. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On 6/28/05, Dave Airlie [EMAIL PROTECTED] wrote: I can also predict the probable outcome on kernel submission if we use the stub to start building suspend/resume in two different places - DRM and fbdev. My stub isn't your totally fb in the stub, we are only going to put initially interrupt handling, suspend/resume, PCI driver handling and some arbitration into the stub... this is similiar to what was going into the vga class stuff before, myself and benh have been talking this over and believe there is no point having mode setting or monitor detection in a lowlevel stub, I'm starting to think that a stub is a really bad idea. It is going to make it easier to build multiple implementations of the same features in the different drivers. The net result will probably be an increase in the architectural chaos of video drivers. You cannot do intelfb modesetting in the kernel, it needs VBE calls no-one is going to put those near the kernel hopefully... The callgate for getting to mode setting has to be in the kernel. That provides a standard API and a secure user-root transition. After the call is in the kernel each driver can choose to satisfy the call in-kernel or use something like call_userhelper() to do the work in user space. I'm trying to decide if the stub framework is worth the hassle of making generic or whether doing it for each driver is probably less trouble... -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
DRM map design
We should discuss the design of DRM maps so that we don't work at cross purposes. I have a new requirement coming from the egl-driver work that my user space driver does not have root priv so it can't create the maps. This implies that the drivers need to pre-create the maps. To access the maps I rely on doing GetMap and searching for the map I need. My driver does not have the info needed to create the maps even if it had the privs. I have never liked how user space needs to figure out a bunch of info about the hardware and them tell it to the device driver since the device driver obviously already knows all of the info it is being told. The register map should be marked read only or root only. I don't need access to the register map. 1) Should the maps be created once at driver load time or on open/close? I can probably make the egl drivers work either way. 2) Is compatibility maintained by doing a match in AddMap and then returning the matching map? 3) Can the driver pre-build the AGP/PCI gart maps? If these maps are marked differently it is way for my driver to tell AGP from PCI cards. 4) Are there issues with sarea other than the one we talked about with XvMC? 5) I had set things up so that a reset program could access the register/framebuffer maps before the card was initialized. You need that because you can't initialize a card that hasn't been reset. BenH is working on another reset scheme so this may not be needed any more. 6) Is there some need for user space collecting info about the hardware and then feeding it back into the driver that I can't see? 7) Any more issues? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
On 6/28/05, Ian Romanick [EMAIL PROTECTED] wrote: 1) Should the maps be created once at driver load time or on open/close? I can probably make the egl drivers work either way. I did it at neither time in the MGA driver. When I added support there for PCI cards, I added a DMA boot-strap ioctl. User-mode passes in some parameters to the kernel (e.g., size of DMA buffers, requested AGP mode, etc.). The kernel then uses those parameters as guidelines to initialize itself. Any changes the kernel has to make (e.g., 4x AGP was requested, but the card is 0x AGP aka PCI) are communicated back via the same structure. A future development path might allow two independent users, one on each head. How do we handle them setting conflicting requests for AGP mode and DMA buffer size? Should AGP mode be a DRM property? It is easy to add an attribute to the driver. Same for DMA buffer size. We would try to pick the right default value for these in the driver. The attributes would only be used for override if the default was wrong. Make these attributes into DRM properties gets rid of the multiuser problem. 3) Can the driver pre-build the AGP/PCI gart maps? If these maps are marked differently it is way for my driver to tell AGP from PCI cards. I would advise against that. There are (rare) cases where user-mode wants to select AGP parameters, AGP mode vs. PCI mode, etc. If AGP is acquired and those maps added at module load, the only way to make those selections will be via module paramters. Yuck. Is it ok to let non-root users build these maps? Another solution would be to build a default set in and require root priv to override it. Module parameters aren't as bad as they used to be. You can echo/cat from /sys/module/driver/parameter and read/write them while the module is running. Just load the module and then change the defaults with a shell script. For example turn on drm debug while drm is running: echo 1 /sys/module/drm/debug 6) Is there some need for user space collecting info about the hardware and then feeding it back into the driver that I can't see? Yes and no. Detecting certain hardware features in the kernel can add extra bloat. For example, MGA needs to know (at least for G200) whether the card has SDRAM or SGRAM. It's easier to have that in user-mode so that you don't add a big chunk of one-time code to the kernel. This example is a little weak. I think there may be a different way to do this detection than the way X does it. Dunno. Since my drivers aren't running as root they have a hard time collecting info like this. Other solutions: 1) call_userhelper() - user mode driver helper that runs in root context 2) put the complex code in the driver and just mark it _init. It will go poof as soon as the driver load is finished. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
On 6/28/05, Thomas Hellström [EMAIL PROTECTED] wrote: Having thought a bit more about the SAREA problem, I'd like to see the following solution: 1) AddMap returns an error if the flag CONTAINS_LOCK is not set. The first SAREA otherwise for backwards compatibility. 2) The device-specific code returns the number of possible SAREAS and the size of each of them. 3) The first one (containing the lock) is created on init or on open for backwards compatibility. 4) subsequent ones are requested and created by a new IOCTL taking the sarea number as an argument. This IOCTL should be used also for future user space access to the first sarea, since standard lookup will fail if there are a number of SAREA maps greater than one. Refcount for destruction of subsequent maps? You can't let a normal user request an arbitrary number or size of sarea. If the API allows general requests it has to be root only. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 915 DRM PM
On 6/28/05, Donnie Berkholz [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jon Smirl wrote: From what I can tell vesafb use is pretty rare. A while ago I broke things in DRM CVS so that vesafb wouldn't work, it was about two months until we got a complaint. DRM CVS is fixed for vesafb but the long lag indicates that there aren't very many users. After the problem the user switched to radeonfb. Couldn't that be telling you that DRM CVS use is pretty rare, not vesafb? Most people are just using releases, so unless the breakage slipped into 6.8.2, a lot of vesafb users never got near it. I'm only talking about vesafb use in conjunction with DRM. That probably is not a configuration that can be supported well since we do not have the source to the vesafb drivers in the board ROMs. I don't think there are very many people who use vesafb with DRM since fbdev drivers also exist for these cards. Instead of vesafb I would suggest using the fbdev driver. In that case we have the source for both the DRM and fbdev drivers. If the fbdev driver is broken file some bugs and let the developers know. In the i915 case I suggest that the better course of action would be to fix i915 fbdev support than to spend a lot of effort trying to find another solution. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM mappings cleanup
I don't think the radeon driver works at all with this patch, [drm] Initialized drm 1.0.0 20040925 [drm:drm_init] [drm:drm_get_dev] [drm:drm_addmap] offset = 0xfe9e, size = 0x0001, type = 1 [drm:drm_addmap] offset = 0xf400, size = 0x0400, type = 0 Maps are added in radeon_preinit [drm:radeon_preinit] AGP card detected [drm:drm_ctxbitmap_next] drm_ctxbitmap_next bit : 0 [drm:drm_ctxbitmap_init] drm_ctxbitmap_init : 0 [drm:drm_get_head] [drm:drm_get_head] new minor assigned 0 [drm] Initialized radeon 1.16.0 20050311 on minor 0: ATI Technologies Inc Radeon RV250 If [Radeon 9000] [drm] Used old pci detect: framebuffer loaded [drm:drm_stub_open] open inside drmOpen() call [drm:drm_open_helper] pid = 12797, minor = 0 [drm:radeon_driver_open_helper] [drm:drm_setup] [drm:drm_ioctl] pid=12797, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0 [drm:drm_ioctl] pid=12797, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0 [drm:drm_release] open_count = 1 [drm:drm_release] pid = 12797, device = 0xe200, open_count = 1 [drm:drm_fasync] fd = -1, device = 0xe200 [drm:drm_takedown] maps get destroyed [drm:radeon_do_cleanup_cp] [drm:drm_takedown] driver pretakedown completed [drm:drm_rmmap_locked] mtrr_del=2 [drm:drm_takedown] takedown completed [drm:drm_stub_open] [drm:drm_open_helper] pid = 12797, minor = 0 [drm:radeon_driver_open_helper] [drm:drm_setup] [drm:drm_ioctl] pid=12797, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0 [drm:drm_ioctl] pid=12797, cmd=0xc0246400, nr=0x00, dev 0xe200, auth=0 [drm:drm_ioctl] pid=12797, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=0 [drm:drm_ioctl] pid=12797, cmd=0xc0086401, nr=0x01, dev 0xe200, auth=0 [drm:drm_ioctl] pid=12797, cmd=0xc0186404, nr=0x04, dev 0xe200, auth=0 My driver looks for maps, there are none, it exits. [drm:drm_ioctl] ret = ffea [drm:drm_release] open_count = 1 [drm:drm_release] pid = 12797, device = 0xe200, open_count = 1 [drm:drm_fasync] fd = -1, device = 0xe200 [drm:drm_takedown] [drm:radeon_do_cleanup_cp] [drm:drm_takedown] driver pretakedown completed [drm:drm_takedown] takedown completed [EMAIL PROTECTED] jonsmirl]# -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM mappings cleanup
This fixes so that my egl driver will get started. You probably need
to test it further.
You are creating the maps in radeon_preinit and it only gets called
once at driver load time. Map creation needs to be moved over to the
open_help function so they will get rebuilt each time.
--
Jon Smirl
[EMAIL PROTECTED]
diff --git a/linux-core/drmP.h b/linux-core/drmP.h
--- a/linux-core/drmP.h
+++ b/linux-core/drmP.h
@@ -572,7 +572,6 @@ struct drm_driver {
/* variables */
u32 driver_features;
int dev_priv_size;
- int permanent_maps;
drm_ioctl_desc_t *ioctls;
int num_ioctls;
struct file_operations fops;
@@ -864,15 +863,13 @@ extern int drm_addbufs_pci(drm_device_t
extern int drm_addbufs_fb (drm_device_t * dev, drm_buf_desc_t * request);
extern int drm_addmap(drm_device_t * dev, unsigned int offset,
unsigned int size, drm_map_type_t type,
- drm_map_flags_t flags, drm_map_t ** map_ptr);
+ drm_map_flags_t flags, drm_local_map_t ** map_ptr);
extern int drm_addmap_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_rmmap(drm_device_t *dev, void *handle);
+extern int drm_rmmap(drm_device_t *dev, drm_local_map_t *map);
+extern int drm_rmmap_locked(drm_device_t *dev, drm_local_map_t *map);
extern int drm_rmmap_ioctl(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
-extern int drm_initmap(drm_device_t * dev, unsigned int offset,
- unsigned int size, unsigned int resource, int type,
- int flags);
extern int drm_addbufs(struct inode *inode, struct file *filp,
unsigned int cmd, unsigned long arg);
extern int drm_infobufs(struct inode *inode, struct file *filp,
diff --git a/linux-core/drm_bufs.c b/linux-core/drm_bufs.c
--- a/linux-core/drm_bufs.c
+++ b/linux-core/drm_bufs.c
@@ -48,66 +48,21 @@ unsigned long drm_get_resource_len(drm_d
}
EXPORT_SYMBOL(drm_get_resource_len);
- /**
- * Adjusts the memory offset to its absolute value according to the mapping
- * type. Adds the map to the map list drm_device::maplist. Adds MTRR's where
- * applicable and if supported by the kernel.
- */
-int drm_initmap(drm_device_t * dev, unsigned int offset, unsigned int size,
- unsigned int resource, int type, int flags)
+static drm_local_map_t *drm_find_matching_map(drm_device_t *dev,
+ drm_local_map_t *map)
{
- drm_map_t *map;
- drm_map_list_t *list;
-
- DRM_DEBUG(\n);
-
- if ((offset (~PAGE_MASK)) || (size (~PAGE_MASK)))
- return -EINVAL;
-#if !defined(__sparc__) !defined(__alpha__)
- if (offset + size offset || offset virt_to_phys(high_memory))
- return -EINVAL;
-#endif
- if (!(list = drm_alloc(sizeof(*list), DRM_MEM_MAPS)))
- return -ENOMEM;
- memset(list, 0, sizeof(*list));
-
- if (!(map = drm_alloc(sizeof(*map), DRM_MEM_MAPS))) {
- drm_free(list, sizeof(*list), DRM_MEM_MAPS);
- return -ENOMEM;
- }
-
- *map = (drm_map_t) {
- .offset = offset,.size = size,.type = type,.flags =
- flags,.mtrr = -1,.handle = 0,};
- list-map = map;
-
- DRM_DEBUG(initmap offset = 0x%08lx, size = 0x%08lx, type = %d\n,
- map-offset, map-size, map-type);
+ struct list_head *list;
-#ifdef __alpha__
- map-offset += dev-hose-mem_space-start;
-#endif
- if (drm_core_has_MTRR(dev)) {
- if (map-type == _DRM_FRAME_BUFFER ||
- (map-flags _DRM_WRITE_COMBINING)) {
- map-mtrr = mtrr_add(map-offset, map-size,
- MTRR_TYPE_WRCOMB, 1);
+ list_for_each(list, dev-maplist-head) {
+ drm_map_list_t *entry = list_entry(list, drm_map_list_t, head);
+ if (entry-map map-type == entry-map-type
+ entry-map-offset == map-offset) {
+ return entry-map;
}
}
- if (map-type == _DRM_REGISTERS)
- map-handle = drm_ioremap(map-offset, map-size, dev);
-
- down(dev-struct_sem);
- list_add(list-head, dev-maplist-head);
- up(dev-struct_sem);
-
- dev-driver-permanent_maps = 1;
- DRM_DEBUG(finished\n);
-
- return 0;
+ return NULL;
}
-EXPORT_SYMBOL(drm_initmap);
#ifdef CONFIG_COMPAT
/*
@@ -133,12 +88,12 @@ static unsigned int map32_handle = 0x100
*/
int drm_addmap(drm_device_t * dev, unsigned int offset,
unsigned int size, drm_map_type_t type,
- drm_map_flags_t flags, drm_map_t ** map_ptr)
+ drm_map_flags_t flags, drm_local_map_t ** map_ptr)
{
drm_map_t *map;
drm_map_list_t *list;
drm_dma_handle_t *dmah;
-
+ drm_local_map_t *found_map;
map = drm_alloc(sizeof(*map), DRM_MEM_MAPS);
if (!map)
@@ -168,65 +123,45 @@ int drm_addmap(drm_device_t * dev, unsig
switch (map-type) {
case _DRM_REGISTERS:
- case _DRM_FRAME_BUFFER:{
- /* after all the drivers switch to permanent mapping this should just return an error */
- struct list_head *_list;
-
- /* If permanent maps are implemented, maps must match */
- if (dev-driver-permanent_maps) {
-DRM_DEBUG
-(Looking for: offset = 0x%08lx, size = 0x%08lx, type = %d\n,
- map-offset, map-size, map-type);
-list_for_each(_list, dev-maplist-head) {
- drm_map_list_t
Re: DRM mappings cleanup
On 6/28/05, Eric Anholt [EMAIL PROTECTED] wrote: On Tue, 2005-06-28 at 16:22 -0400, Jon Smirl wrote: This fixes so that my egl driver will get started. You probably need to test it further. You are creating the maps in radeon_preinit and it only gets called once at driver load time. Map creation needs to be moved over to the open_help function so they will get rebuilt each time. open_helper gets called on every single open, which doesn't seem right to me. Instead I was moving it to presetup, which is the first time the device gets opened again after module load or a takedown. That sounds better. I hadn't put much thought into it, I was just trying to get my driver working again. Post a patch with the right fix. Some of the things in DRM that look like unused features to x.org are used by miniglx and my egl driver. Reset support was in this category until Ben decided to do it a different way. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM mappings cleanup
On 6/28/05, Eric Anholt [EMAIL PROTECTED] wrote: I've just committed the previous diff, with the move to presetup. I'm now looking at 2 things: - Cleaning up driver hooks as previously described, so I can propose a patch for it. - Getting BSD working again. I think this is going to require an addmap helper for dealing with PCI resources, but I think I've got a decent API in mind. I need a prebuilt sarea map if you want to do that. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM mappings cleanup
You can make AddMap simpler by using a stack based drm_map_t and then
allocating the real one at the end. It lets you remove all of the
drm_free(map, sizeof(*map), DRM_MEM_MAPS);
This should be done at the very end after all of the error returns:
if (drm_core_has_MTRR(dev)) {
if (map-type == _DRM_FRAME_BUFFER ||
(map-flags _DRM_WRITE_COMBINING)) {
map-mtrr = mtrr_add(map-offset, map-size,
MTRR_TYPE_WRCOMB, 1);
}
}
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM mappings cleanup
These should be inlines in an h file. There people on lkml that will
complain about unneeded symbol exports.
unsigned long drm_get_resource_start(drm_device_t *dev, unsigned int resource)
{
return pci_resource_start(dev-pdev, resource);
}
EXPORT_SYMBOL(drm_get_resource_start);
unsigned long drm_get_resource_len(drm_device_t *dev, unsigned int resource)
{
return pci_resource_len(dev-pdev, resource);
}
EXPORT_SYMBOL(drm_get_resource_len);
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
On 6/28/05, Thomas Hellström [EMAIL PROTECTED] wrote:
You got me wrong. Item 2 above states that the device specific code
specifies the number of possible SAREAS and their sizes to main DRM as
part of its initialization.
typically for two sareas something like
static uint32_t via_sarea_sizes[] = {8192, 4096, 0};
static struct drm_driver driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_HAVE_IRQ |
DRIVER_IRQ_SHARED | DRIVER_IRQ_VBL,
.context_ctor = via_init_context,
.context_dtor = via_final_context,
.vblank_wait = via_driver_vblank_wait,
.
.sarea_sizes = via_sarea_sizes;
New user code can then get a handle to the first sarea by calling
(implementation of a new ioctl)
drmGetSAREA(0, handle, size);
drmGetSAREA(1, handle, size);
whereas drmGetSAREA(2,) and upwards would fail in this case.
/Thomas
That will work since the amount of memory being allocated is
constrained by the driver.
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM mappings cleanup
This ...
if (found_map-size != map-size) {
DRM_DEBUG(Matching maps of type %d with
mismatched sizes, (%ld vs %ld)\n,
map-type, map-size, found_map-size);
found_map-size = map-size;
}
Should be moved into drm_find_matching_map()
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM mappings cleanup
list = drm_alloc(sizeof(*list), DRM_MEM_MAPS); memset(list, 0, sizeof(*list)); same as drm_calloc() -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On 6/28/05, Benjamin Herrenschmidt [EMAIL PROTECTED] wrote: The callgate for getting to mode setting has to be in the kernel. That provides a standard API and a secure user-root transition. After the call is in the kernel each driver can choose to satisfy the call in-kernel or use something like call_userhelper() to do the work in user space. As I explained already, I think it should be a userland daemon, that's really the best way to deal with access control and would fix all of the issues. How do I communicate my desired mode to the daemon? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Duplicate defines in xf86drm.h and drm.h
At one point I had all of the drm drivers working off from a single set of defines in drm.h. Now it appears that most of the structures and defines are duplicated in xf86drm.h, but the first thing xf86drm.h does is include drm.h. All of the symbols are differentiated with a underscore. What this done recently or is this ancient baggage in xf86drm.h that I can remove? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM map design
On 6/28/05, Ian Romanick [EMAIL PROTECTED] wrote: 3) Can the driver pre-build the AGP/PCI gart maps? If these maps are marked differently it is way for my driver to tell AGP from PCI cards. I would advise against that. There are (rare) cases where user-mode wants to select AGP parameters, AGP mode vs. PCI mode, etc. If AGP is acquired and those maps added at module load, the only way to make those selections will be via module paramters. Yuck. Currently the drivers are AddMap'ing multiple little maps over the AGP area, but the area is basically split into two area: private for the master and public for the DRI clients to write to. So to get around the root priv requirement of AddMap I could have DRM initially create a map which only allows master access to AGP space. Then the non-root master could safely AddMap sub-maps which must exist inside of the predefined AGP map. These sub-maps would lower the priv requirements for parts of AGP space and allow the clients to run. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On 6/27/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: And something I've wondered about for a while: - Is the __user annotation supposed to mean this is a value from userland that should be checked for use or this is a pointer to somewhere in userland that needs to be copy_from_usered before use? No idea, someone else should comment on this.. The _user is an annotation for Linus' sparse tool. An explanation of it is here: http://www.linuxjournal.com/article/7272 The checker source is here now: cg-clone rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/sparse.git DRM fails sparse checking with 1000's of errors. Most of the failures are because DRM has unioned iomem address space pointers with ones to system memory. That is probably something that should be fixed in DRM. You can do that on the x86 but it doesn't work on all architectures. I'm sure any one who makes DRM sparse clean would get a big gold star from Linus. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
915 DRM PM
Is it possible to add the suspend/resume support to Intelfb instead of the DRM driver and then just load both drivers? Do we really want to start building another suspend/resume infrastructure inside of DRM if it is possible to address the problem through existing means? It seems to me like this could get very complicated if both DRM and fbdev both start to try controlling suspend/resume. Ben, to fill you in Alan has added hooks in DRM to create a sysdev device. Sysdev devices have suspend/resume hooks thus allowing DRM into the suspend/resume process. This gets around the problem of fbdev being attached to the hooks. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 915 DRM PM
On 6/27/05, Alan Hourihane [EMAIL PROTECTED] wrote: On Mon, Jun 27, 2005 at 09:58:22AM -0400, Jon Smirl wrote: Is it possible to add the suspend/resume support to Intelfb instead of the DRM driver and then just load both drivers? Do we really want to start building another suspend/resume infrastructure inside of DRM if it is possible to address the problem through existing means? It seems to me like this could get very complicated if both DRM and fbdev both start to try controlling suspend/resume. The intelfb driver doesn't support the i9XX series of Intel chips, and also may not actually be loaded in two cases. One is if the user is already using vesafb, and second when the user isn't using fbdev at all. The case for coming up with a low level stub driver, seems to be a little stronger in this case rather than an fbdev/DRM glued approach. I am almost certain that code for adding suspend/resume support to DRM is going to get rejected when it is submitted to the Linux kernel on grounds that it is duplicating existing code. The code in DRM CVS for detecting fbdev and attaching to the PCI ID if it is not there has already been rejected. You could be a pioneer and write the first stub driver. I've looked at the problem and you need about 80% of the fbdev code in the stub. I just didn't think it was worth the engineering effort to split 20 existing fbdev drivers. Since I didn't want to split the drivers I was just using them as the stub. A properly built fbdev driver should be able to passively load into the system and only be activated on suspend/resume. It won't become active until you load fbconsole. vesafb users should shift to the board specific fb drivers if available. If the board specific fb driver isn't working we should simply fix it instead of building and entire architecture to avoid it's use. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM mappings cleanup
I was also working towards a goal of having everything be permanent maps and all be created at initialization time. Future users could then run without needing AddMap. They would just call GetMap to search for the map that they needed. Old code would keep calling AddMap which would return the matched map, at some point it could be eliminated. The egl drivers I am working on don't run as root so I need everything pre-added. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote: I was just looking at r300 code today for my own system. A few things that I think ought to happen for the merge: - Clean up style. Unindented blocks of code, weird whitespace (closing brackets on the same column as the block containing it, rather than the surrounding block), lack of wrapping at 80 columns, etc. - r300_emit_unchecked_state should get renamed (r300_check_and_emit_state?) and its all-caps warnings removed. The code in DRM CVS has been run through the kernel 'scripts/Lindent' program. There has been recent discussion on lkml about changing the script from 80 char lines to something more modern like 120. I'd definitely vote for 120. You will need to do some manual touch up after Lindent. It will mess up formatting of C99 initializers and some constant blocks. The r300 client code is added into the r200 driver, right? Not a third library like radeon/r200/r300. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote: The code in DRM CVS has been run through the kernel 'scripts/Lindent' program. There has been recent discussion on lkml about changing the script from 80 char lines to something more modern like 120. I'd definitely vote for 120. You will need to do some manual touch up after Lindent. It will mess up formatting of C99 initializers and some constant blocks. Please, 80 is standard. I'm sorry, I forgot that you do your development on an EGA adapter. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [R300] drm driver: merge upstream, security, etc
On 6/26/05, Eric Anholt [EMAIL PROTECTED] wrote:
Are you saying this:
if ((offset=dev_priv-fb_location)
(offsetdev_priv-gart_vm_start)) return 0;
is more readable than:
if ((offset = dev_priv-fb_location)
(offset dev_priv-gart_vm_start))
return 0;
Lindent would do this even with the wrap set at 80 columns.
if ((offset=dev_priv-fb_location) (offsetdev_priv-gart_vm_start))
return 0;
This is from the DRM code formatted with an 80 column limit. Lindent
will let strings exceed 80 columns. To me it look like 13 lines of
code turned into 28.
/* If permanent maps are implemented, maps must match */
if (dev-driver-permanent_maps) {
DRM_DEBUG
(Looking for: offset = 0x%08lx, size =
0x%08lx, type = %d\n,
map-offset, map-size, map-type);
list_for_each(_list, dev-maplist-head) {
drm_map_list_t *_entry =
list_entry(_list, drm_map_list_t,
head);
DRM_DEBUG
(Checking: offset = 0x%08lx, size
= 0x%08lx, type = %d\n,
_entry-map-offset,
_entry-map-size,
_entry-map-type);
if (_entry-map
map-type == _entry-map-type
map-offset ==
_entry-map-offset) {
_entry-map-size = map-size;
drm_free(map, sizeof(*map),
DRM_MEM_MAPS);
map = _entry-map;
DRM_DEBUG
(Found existing: offset =
0x%08lx, size = 0x%08lx, type = %d\n,
map-offset, map-size,
map-type);
goto found_it;
}
}
--
Jon Smirl
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
On 6/24/05, Jon Smirl [EMAIL PROTECTED] wrote: I'm update with your changes this morning. I'm still seeing this at system shutdown. I modprobe drm,radeon and then unloaded them (no errors) then shut the system down. With some more experiments, it only happens with radeonfb loaded. You also have to leave drm/radeon loaded when rebooting. If you rmmod them reboot is ok. It is starting to look like something is not right in kernel support for sysdev devices in loadable drivers. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Alan Hourihane [EMAIL PROTECTED] wrote: Jon, I've noticed you've moved drm_pm_init(). The reason it was were it was before is that the sysdev approach needn't and shouldn't be used when fbdev isn't loaded. Alan. It was too complicated gettting all the error paths right. Easier to just add it all of the time, it doesn't hurt anything. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Jon Smirl [EMAIL PROTECTED] wrote: On 6/24/05, Alan Hourihane [EMAIL PROTECTED] wrote: Jon, I've noticed you've moved drm_pm_init(). The reason it was were it was before is that the sysdev approach needn't and shouldn't be used when fbdev isn't loaded. Alan. It was too complicated gettting all the error paths right. Easier to just add it all of the time, it doesn't hurt anything. That's how I ran into the pm problems to begin with. I had a bug in my sarea work that caused an error return and then the pm code started giving me problems. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Alan Hourihane [EMAIL PROTECTED] wrote: On Fri, Jun 24, 2005 at 12:31:06PM -0700, Jon Smirl wrote: CVSROOT: /cvs/dri Module name: drm Repository: drm/linux-core/ Changes by: [EMAIL PROTECTED] 05/06/24 12:31:06 Log message: More err path clean up for drm_pm Add mandatory sysdev shutdown function Modified files: drm/linux-core/: drm_drv.c drm_pm.c Revision ChangesPath 1.120drm/linux-core/drm_drv.c 1.4 drm/linux-core/drm_pm.c Jon, I've noticed you've moved drm_pm_init(). The reason it was were it was before is that the sysdev approach needn't and shouldn't be used when fbdev isn't loaded. Alan. Shouldn't the power management be per device instead of global to DRM? In fbdev it is per device. If it is per device we don't need the global class. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Alan Hourihane [EMAIL PROTECTED] wrote: But as you are registering the sysdev in the case of the DRM being loaded without fbdev, don't you risk the case where the suspend/resume calls get called twice, once by the PCI driver and then later by sysdev ? That's a problem too, but it is complicated to fix the fbdev error case. I can put code back in that will work most of the time. The problem error cases are when multiple DRM drviers are loaded. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: CVS Update: drm (branch: trunk)
On 6/24/05, Alan Hourihane [EMAIL PROTECTED] wrote: Shouldn't the power management be per device instead of global to DRM? In fbdev it is per device. If it is per device we don't need the global class. The class is global, but the call is to the power() function is device specific. Maybe this is incorrect though for multiple cards, and should be moved to per device classes. I added ref counting to the global class so it should work now with multiple cards. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: sysfs_remove_dir bug?
Something in CVS is corrupting memory and causing various failures. My suspicion it is related to the power management code but I haven't been able to track it down. It is possible that this is related. On 6/23/05, Thomas Hellström [EMAIL PROTECTED] wrote: From bug 3609: I don't think this is via specific. Anybody that has a clue? kernel BUG at include/linux/dcache.h:294! invalid operand: [#1] PREEMPT Modules linked in: via drm nsc_ircc snd_pcm_oss snd_mixer_oss snd_seq_oss snd_seq_midi_event snd_seq parport_pc parport psmouse pcspkr snd_via82xx gameport snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_mpu401_uart snd_rawmidi snd_seq_device snd via_ircc irda acerhk amd64_agp agpgart eth1394 sata_via sata_svw libata sbp2 ohci1394 ieee1394 usb_storage usbhid CPU:0 EIP:0060:[c019d25c]Not tainted VLI EFLAGS: 00213246 (2.6.12-gentoo) EIP is at sysfs_remove_dir+0xfc/0x110 eax: ebx: db5aaf30 ecx: edx: ddf6f280 esi: db5aa800 edi: db891d14 ebp: dc5c16c0 esp: dac0de94 ds: 007b es: 007b ss: 0068 Process X (pid: 12235, threadinfo=dac0c000 task=db1835a0) Stack: dc62c9c0 dce3783a c04faea0 db5aaf30 db5aa800 dc62c940 dc5c16c0 c0300670 db5aaf30 db5aaf30 c03006a0 db5aaf30 0002 dc62cb20 df03d72d db5aaf30 dbb71380 df03e3a8 00203282 dac0c000 db5aa800 ddf64c80 Call Trace: [c0300670] kobject_del+0x10/0x20 [c03006a0] kobject_unregister+0x20/0x30 [df03d72d] drm_takedown+0x34d/0x3f0 [drm] [df03e3a8] drm_fasync+0x48/0x90 [drm] [df03e7c5] drm_release+0x3d5/0x540 [drm] [df03d950] drm_version+0x0/0xa0 [drm] [df03dbb3] drm_ioctl+0x1c3/0x23c [drm] [c0246400] udf_create+0x30/0x1b0 [df03d950] drm_version+0x0/0xa0 [drm] [c0246400] udf_create+0x30/0x1b0 [c0172cb7] do_ioctl+0x77/0xb0 [c015f58a] __fput+0x16a/0x1b0 [c015d942] filp_close+0x52/0xa0 [c015d9e8] sys_close+0x58/0xa0 [c010325b] sysenter_past_esp+0x54/0x75 Code: 89 44 24 08 8b 00 89 04 24 e8 c1 a9 fa ff 8b 54 24 08 8b 42 04 89 04 24 e8 32 35 16 00 8b 44 24 08 89 04 24 e8 a6 a9 fa ff eb 93 0f 0b 26 01 a2 94 49 c0 e9 17 ff ff ff 8d b4 26 00 00 00 00 83 /Thomas --- 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 -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/22/05, Thomas Hellström [EMAIL PROTECTED] wrote: Hi. Jon Smirl wrote: On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote: Second choice would be to make a new map type, DRM_VSHM. The specific driver would initmap the needed space at load time. The code implementing it would be identical to DRM_SHM, you just need another map type defined so that you can tell them apart. This scheme does not require anyone to be root and does not have a kernel DOS hole. So back to the original topic. I'll add a new map type DRM_VSHM. When initializing, the chip specific driver needs to do something like this: if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0))) goto err_g1; The map needs to be created in the driver. Opening it up to a normal user is a DOS hole where the kernel can be run out of memory. Use getmap to find the map from user space. Really what is needed is a shmget thingy that returns a handle to a map which is only mappable by authorized clients. If I understand your solution above, there would be only one extra shared map, and it needs to be looked up from user space, which would be equivalent to allocating a twice as large primary sarea and reserve half of it to applications other than OpenGL, and is hence not needed. The are two maps: 1) the normal sarea, it is always there and it gets allocated by the drm core. Used by core and drive GL like the current code. 2) an optional second shared memory. It is allocated by the card specific driver which also controls its size. Used for additional driver specifc features like XvMC. The second map will always be available in the driver if it has been allocated. If user space wants to use the second map it has to get its address; getmap is used to find the address. Both the first and second maps follow the authorization rules. Why not have a thing similar to drmAddMap doing this (but not root-only)? With proper checks I can't see why that would be a bigger security hole than shmget? To achieve the best security AddMap in its current form needs to be eliminated. All maps would be created by the drivers, not user space. For backwards compatibility AddMap is kept and it returns the matching permanent map instead of creating a new one. /Thomas -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
radeon CVS memory corruption
ins/rmmod of CVS radeon DRM is corrupting kernel memory when fbdev is loaded. Core DRM is ok. You don't see the problem until you rmmod the radeon module. Then after a few seconds the kernel will sometimes report slab corruption. Memory is probably always corrupted but the kernel doesn't always find it. Length is always 4096. I fixed some possible issues with the pm code but I still haven't tracked the problem down. Jun 22 10:18:56 jonsmirl kernel: Slab corruption: start=e466b000, len=4096 Jun 22 10:18:56 jonsmirl kernel: 000: 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/22/05, Ian Romanick [EMAIL PROTECTED] wrote: Jon Smirl wrote: I'll add a new map type DRM_VSHM. When initializing, the chip specific driver needs to do something like this: if ((ret = drm_initmap(dev, 0, video_size, 0, _DRM_VSHM, 0))) goto err_g1; The map needs to be created in the driver. Opening it up to a normal user is a DOS hole where the kernel can be run out of memory. Use getmap to find the map from user space. I don't understand what the difference is between DRM_SHM and DRM_VSHM. I understand all the security issues and the root-only issues, so please don't rehash that. Can you just tell me, for example, what documentation would you put in libdrm/xf86drm.h for the DRM_VSHM enum? Adding a new map type so that you can tell them apart doesn't make a lot of sense to me. Won't two different maps have different offsets? Isn't that enough to differentiate between them? Yes the offsets will be different. But how does user space know which one is being used for sarea and which for xvideo support? We could use a flag instead of map type but we are running out of flags. There are 1,000s of map types available. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/22/05, Jon Smirl [EMAIL PROTECTED] wrote: Adding a new map type so that you can tell them apart doesn't make a lot of sense to me. Won't two different maps have different offsets? Isn't that enough to differentiate between them? Yes the offsets will be different. But how does user space know which one is being used for sarea and which for xvideo support? We could use a flag instead of map type but we are running out of flags. There are 1,000s of map types available. How about a new driver private flag instead of a map type? _DRM_PRIVATE = 0x80 /** Driver private mapping */ That is more generic than doing something specific for x video. Drivers using this will expose two maps of type DRM_SHM. The public one will be sarea and the private one will be driver specific. For backward compatibility the bit is clear for the public sarea map. When doing GetMap from user space the loop will need to take into account multiple maps of the same type and then differentiate on the flags. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/22/05, Thomas Hellström [EMAIL PROTECTED] wrote: 1) How is allocating a second fixed sarea different from splitting the first SAREA in two parts? The problem is not space but future expandability and generality. Both the DRM and driver sarea structs go into the first SHM. You can use the second one for whatever you want. We have to leave the organization of the first SHM alone to keep existing binaries working. Drivers without XvMC support won't create the second SHM. 2) How is a non-root drmAddMap for shared memory a bigger security risc than shmget? I understand why SAREA containing the lock needs to be permanent, but not subsequent ones. Why can't they be created on demand by the master? The memory being allocated by the drivers is non-swappable kernel memory. shmget is allocating swapable memory. Device drivers can't user swapable memory. There is a limited amout of kernel space memory available. /Thomas /Thomas -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote: While this will probably work today it will leave little room for future applications of DRI. Can XvMC needs be handled via the V4L interface? I would expect an some point relevant V4L drivers will also get integrated into the DRM/fbdev composite driver. Is 8K of memory not enough for VIA? Or is the problem that there are three structures being placed in sarea: DRM, via DRM, via XvMC. With three structures you can't tell the offset to load the third one at. Could the three structures problem be fixed by just combining the structure defs for via DRM and via XvMC? Another solution is to create another shared memory type. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote: On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote: While this will probably work today it will leave little room for future applications of DRI. Can XvMC needs be handled via the V4L interface? I would expect an some point relevant V4L drivers will also get integrated into the DRM/fbdev composite driver. I haven't actually looked into the V4L interface, but in VIA's own solution they end up with a proprietary decoder interface that uses their V4L kernel driver and needs to be run as root. Imagine a vulnerable media player that accesses remote URLs and needs to be run as root. There are other V4L drivers that don't need to run as root. I would suspect that VIA didn't implement something correctly and triggered the need to be root. i810 XvMC (from which the unichrome driver initially was derived) is also using drm, but I think nobody is really using it. Is 8K of memory not enough for VIA? Or is the problem that there are three structures being placed in sarea: DRM, via DRM, via XvMC. With three structures you can't tell the offset to load the third one at. Could the three structures problem be fixed by just combining the structure defs for via DRM and via XvMC? It is sufficient today. My point is that we'll be restricting the generality of drm. After som continous development of OpenGL and XvMC the private part of the sarea would look like - OpenGL stuff - XvMC stuff - XvmC lock array - More OpenGL stuff - Continuation of XvMC lock array _ Even More OpenGL stuff __ and therefore IMHO the cleanest solution is to have an XvMC private sarea of it's own, and I'd like to be able to reserve shared memory pages for authenticated clients only, and I believe the DRM is the right place for this. I'm working on changing DRM such that the master node does not need to run as root and instead can be a normal user. Because of this I can't leave AddMap the way it is. The security hole is that a normal user could allocate multi/large shared areas, consume all of kernel VM space and crash the kernel. My first choice would be to push these locks into the driver's V4L interface. Second choice would be to make a new map type, DRM_VSHM. The specific driver would initmap the needed space at load time. The code implementing it would be identical to DRM_SHM, you just need another map type defined so that you can tell them apart. This scheme does not require anyone to be root and does not have a kernel DOS hole. However, the V4L interface is directly manipulable by the user - it does not have a driver library driving it. I don't see how you are going to be able to build V4L if the locks are managed through DRM. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote: On 6/21/05, Jon Smirl [EMAIL PROTECTED] wrote: On 6/21/05, Thomas Hellström [EMAIL PROTECTED] wrote: While this will probably work today it will leave little room for future applications of DRI. Can XvMC needs be handled via the V4L interface? I would expect an some point relevant V4L drivers will also get integrated into the DRM/fbdev composite driver. the problem is v4l is linux specific while XvMC is X specific and hence multi-platform, plus it has ties to Xv, which would need to be handled as well. Don't we already have an Xv for V4L driver for X? Can't XvMC follow the same model? -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote: Exactly. v4l is basically just an analog video capture API. Here is the V4L API spec: http://v4l2spec.bytesex.org/spec/ It supports much more than analog video capature. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/21/05, Vladimir Dergachev [EMAIL PROTECTED] wrote: driver out of it. Exactly. v4l is basically just an analog video capture API. It would be nice to have a v4l compatible interface to the radeon capture interface for AIW and VIVO cards; this would require the drm as well. That's another potential user. The radeon v4l driver km is now maintained and developed by Antti Ajanki. The cooperation of drm is needed for acknowledging interrupts, otherwise they are pretty much orthogonal - km uses RADEON_GUI_DMA registers for transfers from video memory to system ram. I'm working towards a model where there are multiple device specific drivers: radeonfb/fbdev - lowest layer binds to PCI ID, interupts, etc radeon/DRM - coordinates things like memory management and interrupts by linking to fbdev km/v4L - would coordinate interrupts by tying into fbdev like DRM fbdev, DRM, v4L all expose their own device nodes. It should be safe for a normal user to access any of these device nodes instead of requiring root. A variation on the model is: radeon_base radeonfb/fbdev radeon/DRM km/v4L radeon_base is a platform the other drivers load on top of. It is constructed by splitting the existing radeonfb. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/21/05, Alex Deucher [EMAIL PROTECTED] wrote: Exactly. v4l is basically just an analog video capture API. It would be nice to have a v4l compatible interface to the radeon capture interface for AIW and VIVO cards; this would require the drm as well. That's another potential user. v4l is a kernel interface. A radeon v4l driver needs to coordinate with DRM via driver entry points, not a user space IOCTL. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/21/05, Dave Airlie [EMAIL PROTECTED] wrote: I think we should have a root master process to be honest, it can run from init and also have it do any mode setting type business... it can operate like the DDXes do today, except it won't do any mode settting or anything until prompted by the user app... I just feel in-kernel is going to become bloated with what is the DDX _dri.x file now ... just because MS put lots of things in kernel doesn't mean we have to... Getting rid of the root requirement is driven by the desire to lower the amount of code running with root priv. In the x.org tree there are 17,618,401 lines of source and lots of it is running as root. I can not say for sure that all of that code is free from security holes. It is much easier to audit a limited set of driver code that is around 100,000 lines. Whole Linux kernel is 6.7M. I don't see this process adding huge amounts of code to the drivers, I'm halfway through and I don't think I've added hardly any code at all. Mostly I just rearrange what is already there. Linux already has existing fbdev drivers for mode setting. I am choosing to use those now since I wasted a year messing around trying to add mode setting directly to DRM. I now realize that there are vocal, powerful supporters behind using the fbdev code. I want to get my server working so I am choosing the path of least resistance and using fbdev. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: DRM and permanent SAREA
On 6/21/05, Dave Airlie [EMAIL PROTECTED] wrote: I don't see this process adding huge amounts of code to the drivers, I'm halfway through and I don't think I've added hardly any code at all. Mostly I just rearrange what is already there. Linux already has existing fbdev drivers for mode setting. I am choosing to use those now since I wasted a year messing around trying to add mode setting directly to DRM. I now realize that there are vocal, powerful supporters behind using the fbdev code. I want to get my server working so I am choosing the path of least resistance and using fbdev. But there are also people who are against it and my thinking is that with benh now thinking we should avoid using fbdev, we should maybe start to think about it.. I wish you luck in chasing this. I have wasted far, far, far too much time fighting various people over the mode setting API. I have thousands of lines of rejected patches sitting on my disk. I have learned my lesson and the code I am currently writing calls fbdev. -- Jon Smirl [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
