VT Switching with Atomic Modeset

[Daniel Vetter]

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.

Which problem are you trying to solve by avoiding the system compositor
part? 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.

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