Collect all the parent of a given device and pass that to the device
dialog, so we can show and potentially authorize/enroll all the
parent devices too.
Add an expander that contains a list of all the parent devices of
the dialog's target device. If any of the devices is not yet
authorized, show a warning symbol next to it.
Additionally the enroll/authorize function calls are replaced
by a single bolt_client_connect_all call, so parents that need
authorization can be authorized/enrolled too.
The CcBoltDeviceEntry can now optionally show a warning indicator
if the device is in the pending state.
Since we *don't* want to show this in the main list, remove calls
to gtk_widget_show_all and replace them with gtk_widget_show.
Adds a utility function that deterministically generates an object
path from a path base and an object id.
The corresponding bolt commit is:
a396eb986611ed73fc0ccca2127f29ab1e3aac62
Import five commits that add methods to enroll and authorize multiple
devices at once; meant for authorizing a target device and all the
parents that need to be authorized.
Commits in bolt are:
1ae5c8611fc21c21c8c63ba6933b63eb4c20ab87
d993ca2f871e7e412b4e1f885b24e4f6622dfc55
2689e5f77496ac7698744e582feb9afa3e55e0ac
87762ce14650263ef35f97da5a3a5d122ac0b7d7
5aa5548d6c7fa1fa26733ecd073097bc1b9d31fb
00b3d8a35835b8c856e5de026a0c8316b2ceba90
Listen for security level changes, which in theory should not really
happen at all with the exception that on hardware where force power
is not support and boltd has not yet seen the thunderbolt controller
because it was powered down. Then we should get an initial change
from 'unknown' to the real level. Handle it in the same way that
as if boltd was restarted, i.e. the dbus name owner changed
If bolt cannot determine the security level, which in theory should
never happen[1] the standard no-thunderbolt message seems not
entirely appropriate. Instead show a different message that is more
tailored to this unusual case.
[1] The following (unlikely) reasons would invoke such a scenario:
- new security level not supported by boltd
- old hardware with not force-power support and the thunderbolt
controller has not yet been powered up
In the async version of the client creation, i.e. when a new client
is created via bolt_client_new_async and an error happens it will be
passed to g_task_return_error which takes ownership of it but the very
same error will also be free'd via g_autoptr; remove the latter.
This is a port of bolt commit e96f8bd47587b167ae46c8ac9347003f69f931dd
The 'Devices' page is a fitting place for the thunderbolt, being
an IO technology. It is expected that people that need to go to
that page will be sent there via a gnome-shell notification, so
there is no need for it to be on the main page.
Ok'ed by the design team (jimmac).
Thunderbolt devices need to be approved before they can be used.
This is done via the boltd system daemon and gnome-shell. The new
panel enables the user to manage thunderbolt devices, i.e.:
- forget devices that have previously been authorized
- authorize currently unauthorize devices
Additionally authorization of devices an be temporarily disabled
to ensure no evil device will gain access to the computers
resources.
File starting with "bolt-" are copied from bolt's source tree
and currently correspond to the bolt upstream commit with the id
f22b1cd6104bdc2b33a95d9896b50f29a141b8d8
They can be updated from bolt via the update-from-bolt.sh script.
