| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This bigger patch changes the way gRPC proxy client connects to the
server, more specifically how it binds to the same agl_shell interface
as the shell client.
I debated if this should be split into more pieces but I think it makes
more sense to have contained into a single patch as it doesn't make
sense to have some bits off and some bits on, as both the server and the
client side need to be changed at the same time.
This biggest change with this patch is to avoid a potential race condition
between the gRPC proxy client and the shell-client, but also to simplify
the way the gRPC client connects to the server as there aren't sufficient
guards in the server to the provent various corner cases to take place.
Rather than attempting to fix that, simplifying the entire bit and
allow only a single agl-shell client and a sigle gRPC proxy client
connected at a single time and remove any other potential clients
trying to connect at all, later on.
Context and usage:
Both the gRPC proxy and shell-client bind to the same agl_shell
interface, meaning that both use the shell-client (homescreen,
flutter-ics-homescreen, flutter-auto, wam) and the gRPC proxy can
issue agl_shell requests, with some minor differences --
setting background and panels which do not make sense for
gRPC proxy client.
The compositor can signal back to clients when a bind was OK or
not with the bound_ok/bound_fail event. Previously to
adding the bound_ok/bound_fail events, any other client trying to use
agl_shell interface, more than once, would get a protocol violation.
With the bound_ok/bound_fail events clients would instead receive this
event and could theoretically act upon it.
The race that this patch tries to overcome is that the gRPC client will
periodically attempt to verify if there's a shell-client already
connected to server by binding to agl_shell interface and waiting for
bound_fail event. In case it got bound_ok, it would disconnect and
attempt at latter point in time, until it got the bound_failed event, and thus
signalling that there's shell client already connected, allowing to
proceed further.
This worked fine most of the time, depending on how fast the shell
client also bind to agl_shell. For a brief period of time, it might be
that shell client also gets a bound_fail, requiring it to retry at a
later point in time. The disconnected/reconnect of the gRPC proxy would
then complicate matters as the client resources will get overwritten. So
rather than trying to try that fix that, a better approach is to
simplify the way this works entirely.
The change in this patch is that the gRPC proxy doesn't
connect/disconnect periodically but rather it waits for the compositor
to signal when it is ready to bind to agl_shell interface.
That happens with the help of the doas event status, from the
agl_shell_ext interface. If this event status is alright (OK) then it means
the gRPC can then bind to agl_shell interface.
If it gets a failed status it would just wait and then issue another
doas request and continue as such forever until it got an alright
status. The distinct is that in this case the gRPC proxy would not disconnect
and then reconnect retrying the same thing.
This change to simplify some of the assumption in server, and
client side implementation would just race with the shell client when
binding to the agl_shell interface.
Bug-AGL: SPEC-4977
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ib74f789553d3b130ee8e61d0068e617dc2209a58
|
|
This would speed the time checking if agl-shell was bounded or not.
Shouldn't make that much of a difference but we do not need to wait 250
ms just for testing that.
Bug-AGL: SPEC-4912
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: I8751c1d69898a82a415ba9b756bdfe9657ef0546
|
|
This change moves a bit the start-up sequence of the gRPC server and
when it connects to the compositor.
Changing the start-up sequence avoids waiting for the channel to change
its state from disconnected to connected, and only wait for the wayland
connection to take place. Otherwise, we would wait first for the wayland
connection to take place, then wait for the gRPC server to start up
and finally wait for the channel to be in connected state, all which
would incur a massive waiting time.
Moving it a bit early requires to at least verify that we have the proxy
side (the wayland connection) is already set-up at that time.
Bug-AGL: SPEC-4912
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ied88a917df8ff98fefa601103ce04e13c8bb21ac
|
|
These are not seen until enabling the DEBUG directive.
Bug-AGL: SPEC-4912
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ic18c701909975978e82ef811ade416d802e567b5
|
|
Maybe the third time is a charm to avoid fall through and assume on the
exit path we do have a wl_display.
Bug-AGL: SPEC-4935
Reported-by: Lisandro Pérez Meyer <lpmeyer@ics.com>
Tested-by: Lisandro Pérez Meyer <lpmeyer@ics.com>
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: I4adef5bf72d6b1a32a218bf1cfa6c8ed4450ba48
|
|
Commit d8e72099ecbcad, 'grpc-proxy: Terminate thread when we're
exiting', addressed a rather bigger issue to handle correctly the
shutdown/restart sequence. A consequence of that is the initial issue
opened in SPEC-4935 with a trace showing a protocol issue, due to fact
we're supplying an invalid wl_display without being connected to the
compositor.
While commit d8e72099ecbcad, 'grpc-proxy: Terminate thread when we're
exiting' does fix the issue and would make the underlying bug disappear
let's be more pedantic and don't attempt assume we have a compositor
connection when in fact we do not.
Bug-AGL: SPEC-4935
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Id10dabe5178f52fa6a0cf6d70c70799c98f4b6d5
|
|
We need to be joining the thread to be able to exit properly, so let us
do that.
Bug-AGL: SPEC-4935
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ib4e54fcb23267b632f61c10d6ec2835c55ec2f23
|
|
This adds basic scaling for floating windows, sending new dimensions to
the clients to resize itself.
Bug-AGL: SPEC-4862
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ic693153cd704b278dcddd2514afc8dafecf8829b
|
|
This adds basic movement for floating type of windows. The window needs
to be a floating type for this request to work out.
For the agl-shell protocol, this adds a set_app_float() request while
for gRPC it adds a SetAppPosition() request.
Bug-AGL: SPEC-4863
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: I5ecc4257c3e84d15a8cabb183757753be37867f5
|
|
This is identical to the remote role, but I feel this conveys more
information than remote role, as remote denotes that the output is
displayed on another device, which it isn't always the case (the
system has multiple outputs all connected directly).
This introduces two new additions to the agl-shell protocol, a request
to use a different output to display/show the application and an event
to inform the shell client to use as a map between the application id
and its output. The event is necessary to let the shell client know
which output to activate the application on.
This requests implements a wrapper for gRPC that maps 1-to-1 to the
agl-shell request. There's no gRPC subscription similar to the event
though.
Bug-AGL: SPEC-4673
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: I070e9fdbafd5616f3a98415193bf846aeaee9a4a
|
|
This implements set_app_fullscreen which clients can set-up before being
mapped.
The worthwhile change here was the fact that transitioning between
fullscreen, normal, and float would cause invalid tracking of the active
window when switching between these states. This would make floating
operation display the incorrect active window, so in order to reconcile
that, we only update the previous surface if it is different that the
current active one. Otherwise this fairly similar to set_app_float.
Bug-AGL: SPEC-4673
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ie912c86ff7ac38d034cf4d97b2adbc5ef47ce9d3
|
|
Add support for setting a window as float/popup. This allows either the
application itself be set-up as float, or from other gRPC clients.
Bug-AGL: SPEC-4673
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ic7ee8203cd9c4dfcc51b7fc9709f35be504ae9d0
|
|
This request will hide the currently active window, and activate
either the background or the previously active window.
This request mimics the agl-shell-desktop request, actually using the
same code path. It only handles regular windows and float/pop-up. Once
we add other roles like fullscreen/split we can improve on this.
Bug-AGL: SPEC-4673
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: I593cda5d008dfc32fe5e3b079fad9450dc1a490d
|
|
This brings in support for accessing agl-shell protocol indirectly by
using a gRPC interface which bridges the communication between a
particular client (the client issuing gRPC requests) and the AGL
compositor which does that by re-using the same agl-shell protocol.
In order to achieve that, and further more, to avoid having ifdefs code
in the compositor and deal with threading, we instead resorted to using
a helper client.
On one side this helper implements the gRPC server API,
and on the other, a wayland native client that implements the
agl_shell interface.
It uses the agl_shell_ext interface added
previously to communicate with the compositor that it requires access
to agl_shell interface as well. The helper expects that agl_shell interface
was already bounded to another client before starting it so it waits
until that happens and then it implements the protocol specification,
for each interface.
Launching the helper client automatically can be done by adding the
following entry to the ini file:
[shell-client-ext]
command=/path/to/agl-shell-grpc-server
The gRPC server implementation only handles the agl_shell interface
until to this point, specifically, the activate_app request, and the
events that were adedd with version 3 of the agl-shell protocol.
Also the implementation uses the Reactor pattern, with Callback service
that greatly simplifies the async version and avoids putting locks to
to handle multiple clients. This should allow multiple clients being
connected to the gRPC server and receive events / send requests.
Bug-AGL: SPEC-4503
Signed-off-by: Marius Vlad <marius.vlad@collabora.com>
Change-Id: Ie870da3caa138394d8dd30f9d22a5552d585d63a
|
Marius Vlad