Hi Luiz, On Wed, Mar 9, 2022 at 1:02 PM Luiz Augusto von Dentz <luiz.dentz@xxxxxxxxx> wrote: > > Hi, > > On Wed, Mar 9, 2022 at 12:44 PM Luiz Augusto von Dentz > <luiz.dentz@xxxxxxxxx> wrote: > > > > Hi, > > > > On Wed, Mar 9, 2022 at 4:10 AM Bastien Nocera <hadess@xxxxxxxxxx> wrote: > > > > > > On Tue, 2022-03-08 at 14:50 -0800, Sonny Sasaka wrote: > > > > Hi Bastien, > > > > > > > > > > > > On Tue, Mar 8, 2022 at 2:14 AM Bastien Nocera <hadess@xxxxxxxxxx> > > > > wrote: > > > > > > > > > > Hey Katherine, > > > > > > > > > > On Mon, 2022-03-07 at 10:57 -0800, Katherine Lai wrote: > > > > > > Background > > > > > > > > > > > > It was found that a change to the default settings for > > > > > > MinConnectionInterval and MaxConnectionInterval in main.conf > > > > > > broke > > > > > > some of ChromeOS’s keyboard HID tests for only certain Bluetooth > > > > > > controllers. These keyboards aren’t able to connect to the > > > > > > device. > > > > > > Since those connection parameters improve the connection interval > > > > > > for > > > > > > most other chipsets, we want to leave the default values but have > > > > > > a > > > > > > way to have an optional override to address problematic models. > > > > > > > > > > > > > > > > > > Proposed Solution > > > > > > > > > > > > Adding support to bluetoothd for an additional config directory > > > > > > /etc/bluetooth/main.conf.d containing multiple files which will > > > > > > override common params. Override order will be lexically sorted > > > > > > filename order. This pattern is already used by Linux distros, > > > > > > for > > > > > > example there is /etc/sudoers.d which files will override common > > > > > > params in /etc/sudoers. > > > > > > > > > > > > Users can add override config files to /etc/bluetooth/main.conf.d > > > > > > rather than directly editing /etc/bluetooth/main.conf. This is > > > > > > more > > > > > > friendly to package managers since BlueZ package updates won't > > > > > > cause > > > > > > conflict to /etc/bluetooth/main.conf. > > > > > > > > > > > > In bluez’s main.c, merge the params for each *.conf file from > > > > > > /etc/bluetooth/main.conf.d with the existing > > > > > > /etc/bluetooth/main.conf > > > > > > in lexical filename order > > > > > > > > > > > > /etc/bluetooth/main.conf.d will be configurable at build time, > > > > > > e.g. > > > > > > with ./configure --main-conf-dir > > > > > > > > > > This isn't quite how the pattern is usually used. With the existing > > > > > patterns, the OS-supplied stock configuration would be in > > > > > /usr/lib/bluetooth/main.conf.d (maybe with the default .conf in the > > > > > same directory as that subdir), with /etc/bluetooth/main.conf.d > > > > > only > > > > > used for the user/admin override the default configuration. > > > > We did a bit of research and found that /etc/X and /etc/X.d is more > > > > common, e.g. the one described in > > > > https://www.redhat.com/sysadmin/etc-configuration-directories. > > > > > > This is documentation for an enterprise distribution, not how the > > > pattern is now used upstream. > > > > > > $ ls -d1 /usr/lib/*.d/ > > > /usr/lib/binfmt.d/ > > > /usr/lib/environment.d/ > > > /usr/lib/modprobe.d/ > > > /usr/lib/modules-load.d/ > > > /usr/lib/motd.d/ > > > /usr/lib/pam.d/ > > > /usr/lib/sysctl.d/ > > > /usr/lib/sysusers.d/ > > > /usr/lib/tmpfiles.d/ > > > $ ls -d1 /usr/lib/*/*.d/ > > > /usr/lib/dracut/dracut.conf.d/ > > > /usr/lib/dracut/modules.d/ > > > /usr/lib/fedora-third-party/conf.d/ > > > /usr/lib/gconv/gconv-modules.d/ > > > /usr/lib/kernel/install.d/ > > > /usr/lib/NetworkManager/conf.d/ > > > /usr/lib/NetworkManager/dispatcher.d/ > > > /usr/lib/rpm/macros.d/ > > > /usr/lib/systemd/ntp-units.d/ > > > /usr/lib/udev/hwdb.d/ > > > /usr/lib/udev/rules.d/ > > > > > > > If some distribution wants to organize the conf files to > > > > /usr/lib/bluetooth (for stock by package managers) and > > > > /etc/bluetooth/main.conf.d (for admin/users), I guess this is where > > > > having a configurable path is useful. > > > > What do you think? > > > > > > I'm saying this isn't the current pattern, especially for OSes where > > > /usr is locked-down. I still think this isn't the right way to > > > implement this feature. > > > > Before we start doing this we should check if the devices with > > problems don't implement Peripheral Preferred Connection Parameters > > (PPCP) as some of peripherals are not capable of updating the > > connection parameters themselves they depend on the central reading > > the PPCP, some years back we got someone attempting to implement PPCP > > support but the problem was that one needs to load all the devices > > connection parameters with Peripheral Preferred Connection Parameters > > management command, anyway it would be great to have support for PPCP > > even if that means reloading everything or perhaps we introduce > > something at socket level where the user can set the parameters which > > then gets saved once the update connection parameters procedure is > > completed. In our case, the problem is not with the peripherals but with a specific Bluetooth controller of the central. We can't assume that all Bluetooth controllers behave well with a certain configuration, therefore I think that trying to get a one-size-fits-all configuration will likely run into a problem eventually. Also, although it's motivated by a specific issue, the solution that we are proposing is actually a generally helpful feature since there are other parameters that users may override without modifying the original configuration that comes from package manager especially when it is locked down. As a generic override mechanism, what do you think about this proposal? > > Here it is the RFC for the kernel side: > > https://www.spinics.net/lists/linux-bluetooth/msg69520.html > > It probably needs some improvements like checkinf if the conneciton is > really LE, etc. > > > -- > > Luiz Augusto von Dentz > > > > -- > Luiz Augusto von Dentz
