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:
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 ... 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). 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