[lkml]   [2006]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OpenGL-based framebuffer concepts
    On 5/31/06, D. Hazelton <> wrote:
    > As to having seperate devices per user - the only cases this would be really
    > required are:
    > 1) Multiple users logged onto different VT's
    > 2) Remote users doing server-side acceleration of graphics
    > For #1 there is no need for seperate devices, since both users are using the
    > same display and input methods (unless configured different - say with
    > multiple heads and input devices, in which case the second head would already
    > have a node available for it).

    WIth multiple users logged into each head the heads need to be
    controlled independently. One user might set text mode and the other
    1024x768 graphics. The IOCTL will need to list the different modes
    available for each monitor. Some matrox cards support three heads so
    they get three devices. Things are much simpler if there is one device
    node per monitor/head.

    This brings up the problem of merged fb support.

    1) heads are owned by two different users, no merged fb modes available
    2) heads are owned by same user, merged fb modes appear in the mode list
    3) if a mode is in the list, then you can set it
    4) setting a merged fb mode on one device node will make the other
    device node return some kind of error if you try and use it.
    5) A head owned by PAM ( no logged in user) functions as a wild card.
    If you have control of the other head you can set merged fb mode and
    disable PAM.

    DRM will need some work to be able to deal with this.

    Jon Smirl
    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: 2006-06-01 04:52    [W:0.020 / U:4.180 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site