On Tue, 9 Aug 2016, Daniel Vetter wrote: > 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. (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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
