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
