On Mon, 8 Aug 2016, Daniel Vetter wrote: > On Sun, Aug 07, 2016 at 06:41:11PM -0500, Scot Doyle wrote: > > Hi all, > > > > I'm interested in discussing ways compositors could cooperate > > without CONFIG_VT/VT_VACTIVATE/VT_SETMODE. > > > > Daniel wrote up a nice article "VT Switching with Atomic Modeset" [1] > > inviting discussion on dri-devel (about much more than, but including > > this), David posted recently about it on dri-devel [2] and Noralf also > > posted the "DRM text mode" patch series. Hi Daniel, thanks for taking the time to respond. > Which problem are you trying to solve by avoiding the system compositor > part? Providing a transition path away from CONFIG_VT for those users who would otherwise prefer CONFIG_VT to using a system compositor. And as a bonus decreasing the usage of CONFIG_VT. > Afaiui there's not just the drm console, but all the other resources > assigned to a seat (input, audio, whatever) which also need to be > switched. And doing that imo makes much more sense if it's all done in > userspace. I agree that #5-#9 aren't necessary in the case of a system compositor. Would they would make sense as a config option? > Other parts of your plan (like a sysrq for the drm_text console) makes > sense, but those also don't need new ioctls. > -Daniel > > > So, maybe I could continue the discussion by proposing some DRM > > interface additions. > > > > The goals of the proposal are to > > - not affect current CONFIG_VT operation > > - enable compositor switching [1] > > - without a system compositor or intermediary [1] > > - without CONFIG_VT [2] > > - be compatible with the in-kernel DRM text mode [3] > > - provide manual device reset for aberrant states [1] > > - don't consume kernel memory unnecessarily [1] > > - provide DRM clients with access to device boot state [1] > > - remain compatible with legacy DRM/KMS interface [1] > > - remain compatible with future atomic properties [1] > > - leave as many policy decisions to userspace as practical [1] > > > > The "boot state" is the device state after any hardware and firmware > > initialization, but before the DRM device driver is loaded. Since > > different DRM clients (compositors) may want access to this state, > > and no intermediary userspace process should be required, this state > > should be stored in the kernel. > > > > Daniel referred to the "reset" state as "FBDEV resets to defaults" [1]. > > I understand it to be the state of a device after the driver has performed > > some positive set of actions to re-initialize the device. It may be more > > or less desirable from a user's or compositor's perspective than boot > > state. > > > > Ideas 5-9 below are not necessary to switch compositors without an > > intermediary, e.g. a compositor could obtain the current drm client > > process id and send a pre-agreed signal. However, since the DRM interface > > already includes the idea of exclusive access to modesetting > > (SET_MASTER/DROP_MASTER), it seemed fitting to extend it using the > > existing ioctl and event model. > > > > > > Implementation overview > > > > 1. Create a SYSRQ that restores all DRM devices to reset state > > > > 2. Kernel saves boot state of atomic-capable DRM devices at driver load > > > > 3. Create new ioctl DRM_IOCTL_DISCARD_BOOT_STATE > > - frees kernel memory used in #2, if boot state not needed > > > > 4. Provide (optional) mechanism to atomic modeset starting from either > > boot or reset state > > - Daniel discussed two possible mechanisms in [1], an extension to > > the GET_PROPERTY ioctl or a new flag for the MODE_ATOMIC ioctl > > - if boot state selected but unavailable (see #3), return error > > > > 5. Create new ioctl DRM_IOCTL_VOLUNTEER_MASTER > > - indicating current master plans to cooperate with other clients > > - reset in each successful DRM_IOCTL_SET_MASTER ioctl > > > > 6. Create new ioctl DRM_IOCTL_REQUEST_MASTER > > - if no root permissions (like DRM_IOCTL_SET_MASTER), return error > > - if no current master, then return error indicating such > > - if current master didn't VOLUNTEER_MASTER, return error > > - else send event DRM_EVENT_MASTER_REQUESTED to current master > > > > 7. Create new event DRM_EVENT_MASTER_REQUESTED > > - sent via the DRM asynchronous read/poll interface > > - recipient may ignore event (e.g. when using CONFIG_VT) > > - recipient, or its agent, may drop master > > > > 8. Modify DRM_IOCTL_DROP_MASTER ioctl > > - send event DRM_EVENT_MASTER_DROPPED > > - to clients that requested master since the latter of > > - the last time this event was sent > > - the last successful DRM_IOCTL_SET_MASTER ioctl > > > > 9. Create new event DRM_EVENT_MASTER_DROPPED > > - sent via the DRM asynchronous read/poll interface > > - recipient issues DRM_IOCTL_SET_MASTER ioctl if still interested > > > > > > I welcome all discussion, being new to this topic. > > > > Thoughts? > > Scot > > > > [1] http://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html > > [2] https://lists.freedesktop.org/archives/dri-devel/2016-August/114517.html > > [3] https://lists.freedesktop.org/archives/dri-devel/2016-July/114208.html > > -- > Daniel Vetter > Software Engineer, Intel Corporation > http://blog.ffwll.ch > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
