[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.263 / U:39.416 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site