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. -- Luiz Augusto von Dentz
