On Wednesday 30 September 2020 12:54:34 Greg Kroah-Hartman wrote:

On Wed, Sep 30, 2020 at 11:46:16AM +0200, Pali Rohár wrote:

quoted

On Wednesday 30 September 2020 11:20:43 Greg Kroah-Hartman wrote:

quoted

On Wed, Sep 30, 2020 at 10:25:34AM +0200, Pali Rohár wrote:

quoted

On Wednesday 30 September 2020 10:02:05 Greg Kroah-Hartman wrote:

quoted

On Tue, Sep 29, 2020 at 11:32:54PM +0200, Pali Rohár wrote:

quoted

CCing other lists and maintainers, hopefully, somebody would have a time to look at it...

On Saturday 08 August 2020 15:27:47 Pali Rohár wrote:

quoted

On Wednesday 15 April 2020 00:56:18 Pali Rohár wrote:

quoted

On Sunday 09 February 2020 14:21:37 Pali Rohár wrote:

quoted

On Saturday 04 January 2020 11:24:36 Pali Rohár wrote:

quoted

On Saturday 04 January 2020 10:44:52 Marcel Holtmann wrote:

quoted

Hi Pali,

quoted

I wrote a simple script "sco_features.pl" which show all supported
codecs by local HCI bluetooth adapter. Script is available at:

https://github.com/pali/hsphfpd-prototype/blob/prototype/sco_features.pl

And I found out that OCF_READ_LOCAL_CODECS HCI command cannot be send by
non-root user. Kernel returns "Operation not permitted" error.

What is reason that kernel blocks OCF_READ_LOCAL_CODECS command for
non-root users? Without it (audio) application does not know which
codecs local bluetooth adapter supports.

E.g. OCF_READ_LOCAL_EXT_FEATURES or OCF_READ_VOICE_SETTING commands can
be send also by non-root user and kernel does not block them.

actually the direct access to HCI commands is being removed. So we have no plans to add new commands into the list since that it what the kernel is suppose to handle. If we wanted to expose this, then it has to be via mgmt.

Hi Marcel! Thank you for information. I have not know that this API is
"deprecated" and is going to be removed. But userspace audio
applications need to know what bluetooth adapter supports, so can you
export result of these commands to userspace? My script linked above
calls: OCF_READ_VOICE_SETTING, OCF_READ_LOCAL_COMMANDS,
OCF_READ_LOCAL_EXT_FEATURES, OCF_READ_LOCAL_CODECS

Hello! Just a gently reminder for this question. How to retrieve
information about supported codecs from userspace by non-root user?
Because running all bluetooth audio applications by root is not really a
solution. Plus if above API for root user is going to be removed, what
is a replacement?

Hello!

I have not got any answer to my email from Marcel for months, so I'm
adding other developers to loop. Could somebody tell me that is the
replacement API if above one is going to be removed?

I was not able to find any documentation where could be described this
API nor information about deprecation / removal.

And are you aware of the fact that removing of API could potentially
break existing applications?

I really need to know which API should I use, because when I use API
which is going to be removed, then my application stops working. And I
really want to avoid it.

Also I have not got any response yet, how can I read list of supported
codecs by bluetooth adapter by ordinary non-root user? Audio application
needs to know list of supported codecs and it is really insane to run it
as root.

Hello! This is just another reminder that I have not got any reply to
this email.

Does silence mean that audio applications are expected to work only
under root account and ordinary users are not able to use audio and list
supported codecs?

Hello! I have not got any reply for this issue for 10 months and if you
are going to remove (or after these 10 months you already did it?)
existing HCI API from kernel it would break existing and working
userspace application. How do you want to handle such regressions?

What git commit caused this regression?

Hello! Marcel in January wrote that access for HCI commands is being
removed from kernel. I do not know if he managed to do it in since
January, but I'm going to check it...

So you don't see a regression/problem, but are saying there is one?

Hello!

Planed removal of used API would be a regression. Marcel wrote that it
is "being removed". Nobody reacted to that fact for 10 months so I did
not know if this comment was lost and removal is already in progress.
Or if something was changed and removal is not planned anymore.

So are you aware that it will break applications?

Does it?

Of course.

quoted

quoted

odd...

I think it is not a good idea to do something and then check what happen
if there are people who know that such thing is in use and for sure it
will break something.

And also I still did not get any response what is the replacement of
that API.

It sounds like only new commands are restricted

So existing are not being removed? It was finally changed and can you confirm it?

so how is that a regression?

thanks,

greg k-h