> I don't agree with everything but the general idea is a good one. > > > There should be master (possibly one for each card) which be the only > > one being able to do this call: > > DRM_IOCTL_MODE_SETCRTC - set CRTC parameters > > (which i assume is set the mode, associat crtc-output and set framebuffer) > > > > Other call can be made by any others client: > > - DRM_IOCTL_MODE_ADDFB - add a new FB object > > - DRM_IOCTL_MODE_RMFB - remove an FB object > > - DRM_IOCTL_MODE_GETFB - get info about an FB object > > ... > I don't feel it is necessary for the clients to be able to create a > framebuffer, why, because from the kernel standpoint where the said > object will live, it will only be a small container containing the > buffer object(s), a list of crtc that is using the buffer object(s) as > a scanout buffer and the information about its size and format. Read > below for more. > > > In order to make this possible pinning a buffer will be done in SETCRTC > > in which a FB that can fit the mode must be given. Thus ADDFB will > > create a buffer but not pinned until used for scan out, so pinning happen > > in SETCRTC. Note that each client does not necessarily create its own > > framebuffer. > > > > The idea behind this is that we can have a daemon (one for each card > > or one for all of them) and this daemon can take framebuffer from client > > and easily change btw scan out buffer (switching from X to console will > > be made by the daemon and X might just not be aware of this). There > > is other use case one can come up with such scheme like developping > > EGL app under X and display its framebuffer by using it as a texture > > in a GL app. > > > > So there is master (big boss of crtcs) and client or slave humble provider > > of framebuffer. One point that might be also usefull is relation btw > > client should we do somethings like parent/child ? So this might looks like > > this (left are parent) > > master (big boss) > > - X server (got its framebuffer) > > - X application > > - sub GL window of this application (might want to have its > > framebuffer) > > - GL application (dri) client running X application (got its > > framebuffer which > > can used as a texture by the compositor, hello redirected direct > > rendering :)) > > - EGL program (got its framebuffer) > > - Console (got its framebuffer) > > - GL app offscreen rendering (no framebuffer for scanout) > > The idea behind this is that parent can use any object created by their > > child in anyway > > they like (this why we call them parent as parent always play with toy > > created by their > > child :o)). Maybe parent could also put restriction on what their child > > can do (which > > is another characteristics of parents). > So why shouldn't the clients be able to creating framebuffer, because > its only needed for in the kernel for setting the mode and for > creating virtual dev nodes. > That is its only used in the cases: > User <-> /dev/dri/0fb1 <-> crtc/output > User <-> /dev/dri/0fb2 <-> virtual > > It should not be used for passing around information to and from > clients and sub clients. A framebuffer (the kernel side object) is not > needed for offscreen rendering in theory only a BufferObject is needed > for that and the userspace api can transmit the needed information > between the different clients and sub client. > > IE: X the server is the client and a gl app rendering to a opengl > framebuffer. This can be handled by a userspace API that is > above/below the kernel sphere of interest. > > > > > If people are happy with this i will update the wiki. > > > > Cheers, > > Jerome Glisse >
Well ain't I'm rude not signing off :) Cheers Jakob "Wlallbraker" Bornecrekrantz. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
