Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
Multi-seat vs no seats policy in the compositor
Description
Some terminology context wrt to seats:
A seat is a collection of input and output devices (keyboard, mice, monitors)
the DRM-backend which is a native back-end requires having a seat present
the seat here is a logical seat, where we group together different inputs and assign them to different outputs
Some terminology context wrt to "activation" (activation is a misnomer and requires some further explanation):
activation of a surface: the process of making that surface currently displayed, receive input
and finally, activation of an application: currently focused application is now displayed to the user. For instance, from the agl-shell protocol. Better explained by the following image:
In the compositor, when performing the activation of an application we should also incorporate the other types, described above: the input focus activation + xdg-shell activation.
But, at this moment, the compositor handles the first and the second items only if there's keyboard present, being inside of handler that is being triggered when the keyboard changes focus. Obviously, if there's no keyboard, there's also no input focus activation nor there's that xdg-shell activation happening. It is worth mentioning that this hasn't been such an issue because we use windows without decorations (so xdg-shell activation won't matter), and because we use touch input, rather than a keyboard. With the introduction of the weston-terminal which uses decorations it is obvious that won't receive nor input nor we see client decorations activated.
This means we need to de-couple activation from keyboard being present.
Coming back to the original issue of problem: not being to be able to handle focus input + xdg-shell activation without a keyboard, was fixed by just adding it inside compositor activation of application, such that relying on a keyboard being present is no longer a requirement.
In order to know which surface to activate/deactivate we hang it off the seat, because naturally when there are multiple seats we assume that you have multiple outputs so you attach inputs to one seat paired with an output and attach others inputs to another seat paired with another output, as it is happens in traditional desktop environments.
So, ultimately this basically means that we assume we have at least a seat being present in the system. Assumption which from testing out r-car3 and rpi4 seem to hold right, but that is because of either we have power knobs which are treated by udev as input devices (the case of r-car3 we actually have a physical switch to turn the board on) while for rpi4 the display driver seem to be categorized as input device. With at least a input device being created we also have a seat, albeit a "fake" seat present. This also means that ini configuration is from required-input=false is also moot here due to this.
Normally not having anything hooked up in the system, wouldn't create a seat, or you can just specify --seat=0, if you believe the system won't need it (some sort of simple displays of data).
Coming back from the patches in https://gerrit.automotivelinux.org/gerrit/c/src/agl-compositor/+/27216 they also incorporate a fix to avoid having seat altogether in the system, but in the same it exposes another issue which I haven't really thought on updating them: what happens if we have multiple seats or with mutiple outputs?
Because we no longer need a seat, we basically make the focus surface global for all possible outputs, but also causes conflict when there are multiple seats: which seat would actually get focus?
So basically, in a more generic matter, these are the following cases to consider
single seat, single output
single seat, multiple outputs
no seat, single output
no seat, multiple outputs
multiple seats, single output
multiple seats, multiple outputs
For IC most likely we have no seat, single output but maybe also single seat single output (we have some sort of knob that controls the information or switch something). For IVI, multiple outputs could become a norm, so I guess w could have either single seat multiple outputs or single seat multiple outputs, with each touch input device controlling an output basically.
So some further questions to thinkg about:
1) The changes from https://gerrit.automotivelinux.org/gerrit/c/src/agl-compositor/+/27216 initially tried to fix a totally different issue wrt to requiring to have a keyboard. Should I just bring only those changes back and leave this multi-seats vs no seat policy off the table for the moment? This is actually a bug fix imo.
2) How we handle the situation where we have multiple seats?
3) How should we handle the situation where to have no seat?
Minor
Some terminology context wrt to seats:
A seat is a collection of input and output devices (keyboard, mice, monitors)
the DRM-backend which is a native back-end requires having a seat present
the seat here is a logical seat, where we group together different inputs and assign them to different outputs
Some terminology context wrt to "activation" (activation is a misnomer and requires some further explanation):
activation of a surface: the process of making that surface currently displayed, receive input
xdg-shell activation of a surface: described better here: https://gitlab.freedesktop.org/wayland/wayland-protocols/-/blob/main/stable/xdg-shell/xdg-shell.xml#L811. It is basically a way to inform the user, visually that the current surface has received focus. Note, not to be confused with the first item above
and finally, activation of an application: currently focused application is now displayed to the user. For instance, from the agl-shell protocol. Better explained by the following image:
In the compositor, when performing the activation of an application we should also incorporate the other types, described above: the input focus activation + xdg-shell activation.
But, at this moment, the compositor handles the first and the second items only if there's keyboard present, being inside of handler that is being triggered when the keyboard changes focus. Obviously, if there's no keyboard, there's also no input focus activation nor there's that xdg-shell activation happening. It is worth mentioning that this hasn't been such an issue because we use windows without decorations (so xdg-shell activation won't matter), and because we use touch input, rather than a keyboard. With the introduction of the weston-terminal which uses decorations it is obvious that won't receive nor input nor we see client decorations activated.
This means we need to de-couple activation from keyboard being present.
The changes from https://gerrit.automotivelinux.org/gerrit/c/src/agl-compositor/+/27216 do just that but they move a bit forward than that, they attempt to also fix a situation where we might not have a seat at all.
Coming back to the original issue of problem: not being to be able to handle focus input + xdg-shell activation without a keyboard, was fixed by just adding it inside compositor activation of application, such that relying on a keyboard being present is no longer a requirement.
In order to know which surface to activate/deactivate we hang it off the seat, because naturally when there are multiple seats we assume that you have multiple outputs so you attach inputs to one seat paired with an output and attach others inputs to another seat paired with another output, as it is happens in traditional desktop environments.
So, ultimately this basically means that we assume we have at least a seat being present in the system. Assumption which from testing out r-car3 and rpi4 seem to hold right, but that is because of either we have power knobs which are treated by udev as input devices (the case of r-car3 we actually have a physical switch to turn the board on) while for rpi4 the display driver seem to be categorized as input device. With at least a input device being created we also have a seat, albeit a "fake" seat present. This also means that ini configuration is from required-input=false is also moot here due to this.
Normally not having anything hooked up in the system, wouldn't create a seat, or you can just specify --seat=0, if you believe the system won't need it (some sort of simple displays of data).
Coming back from the patches in https://gerrit.automotivelinux.org/gerrit/c/src/agl-compositor/+/27216 they also incorporate a fix to avoid having seat altogether in the system, but in the same it exposes another issue which I haven't really thought on updating them: what happens if we have multiple seats or with mutiple outputs?
Because we no longer need a seat, we basically make the focus surface global for all possible outputs, but also causes conflict when there are multiple seats: which seat would actually get focus?
So basically, in a more generic matter, these are the following cases to consider
single seat, single output
single seat, multiple outputs
no seat, single output
no seat, multiple outputs
multiple seats, single output
multiple seats, multiple outputs
For IC most likely we have no seat, single output but maybe also single seat single output (we have some sort of knob that controls the information or switch something). For IVI, multiple outputs could become a norm, so I guess w could have either single seat multiple outputs or single seat multiple outputs, with each touch input device controlling an output basically.
So some further questions to thinkg about:
1) The changes from https://gerrit.automotivelinux.org/gerrit/c/src/agl-compositor/+/27216 initially tried to fix a totally different issue wrt to requiring to have a keyboard. Should I just bring only those changes back and leave this multi-seats vs no seat policy off the table for the moment? This is actually a bug fix imo.
2) How we handle the situation where we have multiple seats?
3) How should we handle the situation where to have no seat?