VT Switching with Atomic Modeset

[Daniel Vetter]

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.


>> > > 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?

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
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch