Am Dienstag, 09. Dezember 2003 11:15 schrieb Keith Whitwell:
Jon Smirl wrote:
My current thinking on this is to do it the DRM driver but store the
allocation
data in normal system RAM. This would allow the allocation
routines to function without touching the framebuffer.
I would
Jon Smirl wrote:
My current thinking on this is to do it the DRM driver but store the allocation
data in normal system RAM. This would allow the allocation routines to function
without touching the framebuffer.
I would really like to make sure that DRM drivers can function without having to
map
On Tue, 2003-12-09 at 02:12, Jon Smirl wrote:
-- Michel Dnzer [EMAIL PROTECTED] wrote:
I think at least the core of it definitely has to be in the kernel for
enforceability, cleanup on process death etc.
You're and expert on the radeon driver, want to help code this up?
You're flattering
On Sat, 2003-12-06 at 19:25, Keith Whitwell wrote:
Why doesn't the DRM module just send a signal on retrace?
It can, you just have to tell it to.
--
Earthling Michel Dnzer | Debian (powerpc), X and DRI developer
Software libre enthusiast|
On Sat, 2003-12-06 at 23:24, Jon Smirl wrote:
3) FB memory allocators. Not sure these should go into the DRM system. It might
be better to put this into the library with init/mode support. Mesa would need
to be modified to use these allocation routines. On the other hand these might
be
My current thinking on this is to do it the DRM driver but store the allocation
data in normal system RAM. This would allow the allocation routines to function
without touching the framebuffer.
I would really like to make sure that DRM drivers can function without having to
map the framebuffer
--- Michel Dänzer [EMAIL PROTECTED] wrote:
I think at least the core of it definitely has to be in the kernel for
enforceability, cleanup on process death etc.
You're and expert on the radeon driver, want to help code this up? I'm still
bogged down with the mode code and making the VM86 work
Could you provide me with an offical API for getting these items? It's stupid to
overlay the stats function to conserve IOCTLs.
DRM_STAT_PCI_VENDOR].value = dev-pdev-vendor;
DRM_STAT_PCI_DEVICE].value = dev-pdev-device;
DRM_STAT_PCI_SUB_VENDOR].value = dev-pdev-subsystem_vendor;
--- Keith Whitwell [EMAIL PROTECTED] wrote:
Why not just make a generic GET_INT_PARAM ioctl, and use that? Or any other
mechanism which you think makes more sense. I don't have a problem with that,
but post a patch to dri-devel see if anyone does. There's no 'official'
body to do this.
Generic things we need in the next DRM rev:
1) Retrieve chip/vendor id, subsys ids
2) location of PCI resources. fb start/end, mmio start/end.
Should we do a new API on this one too? The only thing I use these for is to
pass them back into AddMap. Maybe we could modify AddMap(FBTYPE) to take
10 matches
Mail list logo
