VT Switching with Atomic Modeset

[Scot Doyle]

On Tue, 9 Aug 2016, Daniel Vetter wrote:
> On Tue, Aug 9, 2016 at 9:28 PM, Scot Doyle <lkml14 at scotdoyle.com> wrote:
> > On Tue, 9 Aug 2016, Daniel Vetter wrote:
> >> So if you want the kernel to VT-switch, then imo just enable CONFIG_VT. It
> >> gets the job done, no need for a new uapi (and all the resulting churn in
> >> userspace). Of course the other bits in your plan might still be needed,
> >> but like I said I think those are fairly independent of the actul
> >> VT-switching machinery.
> >
> > Ya, for the other topics in [1] I mainly wanted to share the idea that
> > boot state does not need to consume memory. (See #3 below for a question.)
> > But I don't currently understand this part of drm enough to propose those
> > patches.
> 
> Properties are u64 values, and we store them in an array. Given how
> big the actual data structures are that's probably not worth to
> release.

(see below)

> 
> >> > > 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
> >
> > What did you have in mind when mentioning this wouldn't require an ioctl?
> 
> this = ? Do you mean capturing the boot-up state? And where did I mention this?

Sorry, "this" = the ability to release the memory storing boot-up state 
for each drm device, which I had proposed as an ioctl in #3.

In [1] you wrote "But again storing boot-up state in the kernel would be 
wasteful on systems that will never need it (like Android or CrOS)".

But up above in this message you were thinking it's just a small array of 
u64's, so not important to discard? So then no need for the ioctl?

[1] http://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html


> Side-note aka manual for making best use of your maintainer: I run
> state-free, after hitting send on a mail or publish on a blog post I
> pretty much immediate forget all the details again. Mostly I can
> reconstruct them though from reading things again ;-) But that means
> you need to supply the necessary links for me to reload context ...
> -Daniel