Re: VT Switching with Atomic Modeset

Re: VT Switching with Atomic Modeset

[Scot Doyle]

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.

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VT Switching with Atomic Modeset

[Daniel Vetter]

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.

Which problem are you trying to solve by avoiding the system compositor
part? 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.

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VT Switching with Atomic Modeset

[Scot Doyle]

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?

> 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
> 
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VT Switching with Atomic Modeset

[Daniel Vetter]

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
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VT Switching with Atomic Modeset

[Scot Doyle]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 7833 bytes --]

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

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VT Switching with Atomic Modeset

[Daniel Vetter]

On Tue, Aug 9, 2016 at 9:28 PM, Scot Doyle <lkml14@scotdoyle.com> 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.


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

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
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VT Switching with Atomic Modeset

[Scot Doyle]

On Tue, 9 Aug 2016, Daniel Vetter wrote:
> On Tue, Aug 9, 2016 at 9:28 PM, Scot Doyle <lkml14@scotdoyle.com> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: VT Switching with Atomic Modeset

[Daniel Vetter]

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@scotdoyle.com> 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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel