[lkml]   [2004]   [Sep]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectNew proposed DRM interface design

    Okay I've had some thoughts about the DRM interfaces and did some code
    hacking (drmlib-0-0-1 branch on DRM CVS , very incomplete)

    Below is my proposal for an interface that does introduce a major new
    binary interface (the biggest issue with a straight core/personality split
    for DRI developers, we have enough binary interfaces in our lives)...

    Any comments are appreciated, the document is also available at:


    This documents a proposed new design for the DRM internal kernel interfaces.

    The current DRM suffers from a number of issues with multiple drivers in
    the same kernel (the mess that is the drm_stub.h and parts of drm_drv.h)
    along with the DRM() macros show this up. This design tries to address
    this issue without introducing any major new binary interface.

    I propose a 3 way code split-
    DRM core
    DRM library
    DRM driver

    This is slightly along the lines of the fb where the core is fbmem + co,
    the library is the cfb* object and the driver is the graphics chipset

    What I would like to do for the DRM is not as extreme as the fb approach.
    I propose the following type split:

    DRM core - just the stub registration procedure and handling any
    shared resources like the device major number, and perhaps parts of sysfs
    and class code. This interface gets set in stone as quickly as possible
    and is as minimal as can be, (Jon Smirls dyn-minor patch will help a fair
    bit also). All the core does is allow DRMs to register and de-register in
    a nice easy fashion and not interfere with each other. This drmcore.o can
    either be linked into the kernel (ala the fb core) or a module, but in
    theory it should only really be shipped with the kernel - (for compat
    reasons the DRM tree will ship it for older systems).

    DRM library - this contains all the non-card specific code, AGP
    interface, buffers interface, memory allocation, context handling etc.
    This is mostly stuff that is in templated header files now moved into C
    files along the lines of what I've done in the drmlib-0-0-1-branch. This
    file gets linked into each drm module, if you build two drivers into the
    kernel it gets shared automatically as far as I can see, if you build as
    modules they both end up with the code, for the DRM the single card is the
    primary case so I don't mind losing some resources for having different
    cards in a machine.

    DRM driver - the current driver files converted to the new
    interfaces, I don't mind retaining some of the templating work, I like the
    fact that we don't have 20 implementations of the drm probe or PCI tables
    or anything like that, so I think some small uses of DRM() may still be
    acceptable from a maintenance point of view.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 14:05    [W:0.022 / U:4.276 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site