[BlueZ,v7,6/6] adapter: Remove experimental flag for PowerState

Now that the feature has been tested, that the API is deemed adequate
and the reliability sufficient.
---
 src/adapter.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

Hi everyone,

Can we please apply this one, too? The property being experimental means distros
need to downstream patch BlueZ for the feature to work, I'm not sure all packagers
are aware of that.

FWIW, I can confirm the feature in gnome-shell works after removing the flag!

Cheers,
Jonas

On 9/1/22 13:07, Bastien Nocera wrote:
> Now that the feature has been tested, that the API is deemed adequate
> and the reliability sufficient.
> ---
>   src/adapter.c | 3 +--
>   1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/src/adapter.c b/src/adapter.c
> index 8fb2acdc8..841096d7f 100644
> --- a/src/adapter.c
> +++ b/src/adapter.c
> @@ -3864,8 +3864,7 @@ static const GDBusPropertyTable adapter_properties[] = {
>   	{ "Alias", "s", property_get_alias, property_set_alias },
>   	{ "Class", "u", property_get_class },
>   	{ "Powered", "b", property_get_powered, property_set_powered },
> -	{ "PowerState", "s", property_get_power_state, NULL, NULL,
> -			     G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
> +	{ "PowerState", "s", property_get_power_state },
>   	{ "Discoverable", "b", property_get_discoverable,
>   					property_set_discoverable },
>   	{ "DiscoverableTimeout", "u", property_get_discoverable_timeout,

Hi Jonas,

On Sun, Nov 13, 2022 at 8:03 AM Jonas Dreßler <jonas@dressler.it> wrote:
>
> Hi everyone,
>
> Can we please apply this one, too? The property being experimental means distros
> need to downstream patch BlueZ for the feature to work, I'm not sure all packagers
> are aware of that.

Well experimental can be enabled by passing -E to bluetoothd, so it
can be enabled at runtime, that said we might switch it to stable on
the next release.

> FWIW, I can confirm the feature in gnome-shell works after removing the flag!
>
> Cheers,
> Jonas
>
> On 9/1/22 13:07, Bastien Nocera wrote:
> > Now that the feature has been tested, that the API is deemed adequate
> > and the reliability sufficient.
> > ---
> >   src/adapter.c | 3 +--
> >   1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/src/adapter.c b/src/adapter.c
> > index 8fb2acdc8..841096d7f 100644
> > --- a/src/adapter.c
> > +++ b/src/adapter.c
> > @@ -3864,8 +3864,7 @@ static const GDBusPropertyTable adapter_properties[] = {
> >       { "Alias", "s", property_get_alias, property_set_alias },
> >       { "Class", "u", property_get_class },
> >       { "Powered", "b", property_get_powered, property_set_powered },
> > -     { "PowerState", "s", property_get_power_state, NULL, NULL,
> > -                          G_DBUS_PROPERTY_FLAG_EXPERIMENTAL },
> > +     { "PowerState", "s", property_get_power_state },
> >       { "Discoverable", "b", property_get_discoverable,
> >                                       property_set_discoverable },
> >       { "DiscoverableTimeout", "u", property_get_discoverable_timeout,
>

On Sun, 2022-11-13 at 16:54 +0100, Jonas Dreßler wrote:
> Hi everyone,
> 
> Can we please apply this one, too? The property being experimental
> means distros
> need to downstream patch BlueZ for the feature to work, I'm not sure
> all packagers
> are aware of that.

I enabled it without the experimental flag in Fedora, because I wrote
it, and I know I'll be responsible for it should there be any bugs.

I really don't want to be on the spot for fixing a problem upstream, or
in another distribution if another distribution enables the feature
without testing it, or responsible for fixing their libraries should we
decide that the API isn't good enough.

> FWIW, I can confirm the feature in gnome-shell works after removing
> the flag!