https://bugs.freedesktop.org/show_bug.cgi?id=32511 --- Comment #14 from Tormod Volden <bugzi09.fdo.tormod@xxxxxxxx> 2011-02-12 04:13:17 PST --- I have tracked this down to kernel commit 41c2e75e60200a860a74b7c84a6375c105e7437f: ... But also, because userspace isn't capable of passing such offsets, I had to modify drm_find_matching_map() to ignore the offset passed in for maps of type _DRM_FRAMEBUFFER or _DRM_REGISTERS. If we ever support multiple _DRM_FRAMEBUFFER or _DRM_REGISTERS maps for a given device, we might have to change that trick, but I don't think that happens on any current driver. The savage driver uses one drm map for the framebuffer and a second for the apertures (which for most cards are in the same BAR, but offset by 0x2000000). Since above commit (in 2.6.30) the drm will confuse the two maps, and return the handle of the first when DRI tries to map the second. This explains why the workaround in comment 10 worked (on most cards). I will try to modify the DDX to create only one DRM map which covers both framebuffer and apertures (kind of what happens already). Corresponding changes will be needed in mesa to deal with the offset of the apertures in the framebuffer map. For Paramount and Savage 2000 chipsets it is more complicated, since here the frontbuffer and apertures are in separate PCI BARs. Maybe one drm map can work here also, but the offset may be different. Not sure how to report the offset to mesa without breaking the savage ABI. Or should really the kernel drm be fixed to support multiple framebuffer maps? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
