VT Switching with Atomic Modeset

Tue Aug 9 06:20:04 UTC 2016

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. 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.

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.
-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
> > > 
> > > 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
> > 
> > -- 
> > Daniel Vetter
> > Software Engineer, Intel Corporation
> > http://blog.ffwll.ch
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch