On Tue, Aug 09, 2016 at 02:52:43PM -0500, Scot Doyle wrote: > 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 I guess I changed my opinion ;-) I shouldn't be too bothersome to keep this around I think. Anyway I pondered all this boot-up/default/reset state question a bit more, here's my suggestion for how to move forward: - First we just implement a sysrq handler to beat the kms state back into shape. That way we can figure out how to best store the reset state, and what exactly it should be (there's a few thorny issues in that regard about whether it should be the defaults, or what fbdev emulation would do, or boot-up state or something else), without having to figure out how to expose it to userspace. For the implementation I think it makes sense to restrict to atomic drivers (they are much more sensible wrt state handling). And also to share that reset logic with the fbdev emulation (and maybe later on also be able to use it with drm text or, if that makes sense). - Once we have that we can figure out whether we also need to expose these values to kms clients, and what the ioctls/interface should look like. Getting uapi right is always a bit tricky, and since we need the full stack ready&reviewed, always a bit involved. Cheers, Daniel > > > > 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 http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
