On Tue, 9 Aug 2016, Daniel Vetter wrote: > On Mon, Aug 08, 2016 at 01:32:51PM -0500, Scot Doyle wrote: > > On Mon, 8 Aug 2016, Daniel Vetter wrote: > > > On Sun, Aug 07, 2016 at 06:41:11PM -0500, Scot Doyle wrote: > > > > Hi all, > > > > > > > > I'm interested in discussing ways compositors could cooperate > > > > without CONFIG_VT/VT_VACTIVATE/VT_SETMODE. > > > > > > > > Daniel wrote up a nice article "VT Switching with Atomic Modeset" [1] > > > > inviting discussion on dri-devel (about much more than, but including > > > > this), David posted recently about it on dri-devel [2] and Noralf also > > > > posted the "DRM text mode" patch series. > > > > Hi Daniel, thanks for taking the time to respond. > > > > > Which problem are you trying to solve by avoiding the system compositor > > > part? > > > > Providing a transition path away from CONFIG_VT for those users who would > > otherwise prefer CONFIG_VT to using a system compositor. And as a bonus > > decreasing the usage of CONFIG_VT. > > > > > Afaiui there's not just the drm console, but all the other resources > > > assigned to a seat (input, audio, whatever) which also need to be > > > switched. And doing that imo makes much more sense if it's all done in > > > userspace. > > > > I agree that #5-#9 aren't necessary in the case of a system compositor. > > Would they would make sense as a config option? > > tbh 5-9 look like VT swtiching, reimplemented in DRM. exactly > To me that doesn't > make much sense. It's true that CONFIG_VT is a bit a (locking) horror show > in the implementation, but if that's the only problem we could fix this in > the kernel. Good point. And that it has remained this way for so long is evidence to me of a de facto general consensus. Based on that, I won't submit patches for 5-9. > The real reason people (me included) want to see CONFIG_VT die is that in > our opinion it's simply not the kernel's business to switch between > virtual terminals/login-sessions/... The kernel should provide tools for > that (drm master, similar revoke concepts in input, audio, ...), but then > leave the policying to userspace. Reimplementing CONFIG_VT switching, but > in a different subsystem, doesn't improve things. > > Note that already today (if you set the right I-know-what-I'm-doing > Kconfig options) you can have a CONFIG_VT which does nothing but > VT-switching essentially: Enable the dummy console driver (automatically > done) and disable every other console driver - voilà. That should even > work together still with something like drm text or drmlog as emergency > logging consoles. > > 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. > -Daniel > > > > > > 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? > > > > 4. Provide (optional) mechanism to atomic modeset starting from either > > > > boot or reset state > > > > - Daniel discussed two possible mechanisms in [1], an extension to > > > > the GET_PROPERTY ioctl or a new flag for the MODE_ATOMIC ioctl > > > > - if boot state selected but unavailable (see #3), return error > > > > > > > > 5. Create new ioctl DRM_IOCTL_VOLUNTEER_MASTER > > > > - indicating current master plans to cooperate with other clients > > > > - reset in each successful DRM_IOCTL_SET_MASTER ioctl > > > > > > > > 6. Create new ioctl DRM_IOCTL_REQUEST_MASTER > > > > - if no root permissions (like DRM_IOCTL_SET_MASTER), return error > > > > - if no current master, then return error indicating such > > > > - if current master didn't VOLUNTEER_MASTER, return error > > > > - else send event DRM_EVENT_MASTER_REQUESTED to current master > > > > > > > > 7. Create new event DRM_EVENT_MASTER_REQUESTED > > > > - sent via the DRM asynchronous read/poll interface > > > > - recipient may ignore event (e.g. when using CONFIG_VT) > > > > - recipient, or its agent, may drop master > > > > > > > > 8. Modify DRM_IOCTL_DROP_MASTER ioctl > > > > - send event DRM_EVENT_MASTER_DROPPED > > > > - to clients that requested master since the latter of > > > > - the last time this event was sent > > > > - the last successful DRM_IOCTL_SET_MASTER ioctl > > > > > > > > 9. Create new event DRM_EVENT_MASTER_DROPPED > > > > - sent via the DRM asynchronous read/poll interface > > > > - recipient issues DRM_IOCTL_SET_MASTER ioctl if still interested > > > > > > > > > > > > I welcome all discussion, being new to this topic. > > > > > > > > Thoughts? > > > > Scot > > > > > > > > [1] http://blog.ffwll.ch/2016/01/vt-switching-with-atomic-modeset.html > > > > [2] https://lists.freedesktop.org/archives/dri-devel/2016-August/114517.html > > > > [3] https://lists.freedesktop.org/archives/dri-devel/2016-July/114208.html
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
