On 02/08/07, Jerome Glisse <[EMAIL PROTECTED]> wrote: > Jesse Barnes wrote: > > I finally found some time to create a new wiki page for all the > > modesetting/configuration related DRM enhancements we've been talking about: > > http://dri.freedesktop.org/wiki/DrmModesetting > > > > Please take a look and let me know what you think. I still have to go > > through > > all the feedback I received from the lkml post I made awhile back, and make > > sure it's captured (I think it is, albeit at a fairly high level mostly), > > and > > add more detail in the design and development sections. > > > > Jakub, hopefully you can go over it and add more detail about the userland > > APIs? > > > > Dave and Keith, we talked about the new device node scheme awhile back, but > > I > > only have notes on what the master node should be responsible for, did we > > have any new ioctls for the slave nodes? Ring buffer mapping, etc. should > > probably be there? > > > > Thanks, > > Jesse > > > > > This time i do not hijack the thread :) So we just discussed with Jakob > and Jesse on this on irc and here is what i believe we agreed on:
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 ------------------------------------------------------------------------- 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
