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. > > 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"). Done right, I think this approach could actually *simplify* drivers rather than making them more complex... Jesse ------------------------------------------------------------------------- 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
