On Tue, Aug 9, 2016 at 9:28 PM, Scot Doyle <lkml14@xxxxxxxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
