On Wednesday 30 September 2020 11:20:20 Greg Kroah-Hartman wrote: > On Wed, Sep 30, 2020 at 10:16:40AM +0200, Marcel Holtmann wrote: > > Hi Greg, > > > > >>>>>>>> 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? > > > > there is no regression! > > > > New Bluetooth standards added new HCI commands that are just not > > exposed to unprivileged users. > > Ok, that makes sense. What tool takes advantage of these new HCI > commands?
sco_features as written above (in quoted part). And today also main daemon in that repository. > thanks, > > greg k-h
