Hi > You didn't miss any patches. It was I who missed the usage in drm_crtc.c. > I guess this, and Daniel's reply prompts a discussion about control > nodes and the master concept. > > First I'd like to give some background about the use-case: I'd like to > use the control node for a daemon that tells the vmwgfx driver about the > host GUI layout of the screen: What connectors are enabled, the > preferred mode of each output and some driver private information. The > daemon will run as root and only a single instance per device. Trying to > do this as-is will cause the vmwgfx driver to BUG() because it currently > assumes one active master per device. Not one active master per minor > (although that could be changed if needed). Why do you tie this to DRM-Master? Can't you just limit these special ioctls to the control-node and drop any master-requirements? This way you don't care whether the FD on the control-node is master or not, you just assume that access-rights on the control-node are highly restricted so anyone opening it is privileged to issue these ioctls. > Looking at > > http://dvdhrm.wordpress.com/2013/09/01/splitting-drm-and-kms-device-nodes/ > > it doesn't really make sense to keep the master concept on the control > node, but it perhaps makes sense to keep it on future modesetting nodes > to allow multiple modesetters to open the same device node? > > In that case all master access in drm_crtc.c would be changed for now to > be conditioned on file_priv->minor->type == DRM_MINOR_LEGACY The Master-concept only really makes sense for operations affecting global state. On non-legacy drivers this is basically KMS. Therefore, I see no reason to extend the master-concept to non-modeset/primary nodes. So ACK on changing drm_crtc.c to check for master only if minor==DRM_MINOR_PRIMARY/LEGACY (there are pending patches renaming it..). The problem with the modeset-node concept described in my blog-post is KMS-object hotplugging. We don't support it.. and I don't see any proper way to extend our API in a suitable way. The only thing I still have planned is to allow creating multiple DRM_MINOR_PRIMARY/LEGACY nodes and splitting mode-objects among them. We would have to do that before anyone uses the device to prevent objects from disappearing, but this could easily be done as udev-action. Thus, setting up multiple KMS interfaces on a single card. Anyhow, imho we should just try to remove any master-handling from any core DRM code. Ideally, only drm_drv.c deals with DRM-Master when checking for permissions. Everything else should never attach any information to these things. Especially the master-related driver callbacks are undocumented and really weird. If we'd be able to drop all this, I think we can start looking forward. Thanks David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
