VT Switching with Atomic Modeset

[Scot Doyle]

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
>