On 2/14/08, Jesse Barnes <[EMAIL PROTECTED]> wrote: > On Wednesday, February 13, 2008 3:55 pm Stephane Marchesin wrote: > > > You don't want any application to be able to change CRTC<->output > > > mappings, or bind BOs to CRTCs. Ideally you'd just have one app that > > > could do that on a given system, and it would contain the distribution's > > > policy regarding output cloning, hotplug actions, etc. > > > > I don't see how that interferes with the solution I propose ? I'm not > > discussing policy but where to store the policy. The existence of one > > client being able to scanout at a time is ovbious in any case. > > I don't know if it interferes, but I also can't see how your proposal deals > with this case. Can you provide more details? Just saying a BO has scanout > permission isn't sufficient either, since CRTC<->output mappings are > important too and not covered by BO permissions. >
There is always the possibility of > > > So the master/slave concept is really more analogous to pty master & > > > slave nodes than it is to your /dev/sda_ext3 example. You open the > > > master node, ask for a specific mapping, and if you have permission, a > > > slave node will be created that you can do what you like with... > > > > Yeah, probably my analogy is far from perfect. Since people seem to > > concentrate on the analogy instead of the point, let me state the > > point. My point is that exposing different uses for a device should > > not be exposed through separate /dev entries. GPGPU is obviously a > > very recent trend. Will we have to add new /dev entries for future > > trends as well, and how future proof is that ? > > Sure, I don't think anyone will disagree with that: we shouldn't be > exposing /dev/feature_bong and /dev/feature_hits, however doing a logical > split on device capability (as opposed to application) does make sense. For > instance, sound devices expose mixer, midi, and raw digital audio nodes, > since the functions are relatively independent with their own interfaces and > possibly permissions. Similarly, output control, rendering to a screen and > running programs are separate functions of a modern GPU (though you could > argue that the last is a subset of "rendering to a screen"). > Well, you're using the example of fully in-kernel drivers here. In that case, it does make sense because there is no user space layer to expose different APIs/functionality. However, the DRM is a little different. Its interface doesn't carry "OpenGL" or even "3D" semantics on it, nor does it carry "2D/EXA" nor "GPGPU". However, all these can and are exposed by some user space library using the DRM. And we do not have a need for different interfaces at the kernel level, since our APIs are exposed at some higher level. Stephane ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
