VT Switching with Atomic Modeset

Tue Aug 9 19:28:20 UTC 2016

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