All of
 help / color / mirror / Atom feed
From: Marcel Holtmann <>
To: Katherine Lai <>
Cc: BlueZ <>,
	Sonny Sasaka <>
Subject: Re: [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d
Date: Thu, 10 Mar 2022 10:51:37 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

Hi Katherine,

> 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

actually I rather not do this. Let met try to explain this. In modern distribution layout, the /etc directory is purely for the admin of the system. They can do localized changes. Defaults are meant to be in /usr/lib/ actually. And override is also meant that an /etc file can fully replace an /usr/lib file.

We already structured that /etc/bluetooth/main.conf is optional and that package managers / distros should only install it if they really know what they are doing. If an upgrade of a package overwrites /etc/bluetooth/main.conf then it is doing something wrong (mind you we don’t install it by default).

That said, some time ago I discussed with Alain, that fundamentally you first need an option to identify your controller, what firmware etc. and then can decide what to load. That thread ended and got no further discussion. Based on that identification we wanted to allow tweaking certain set of parameters to add known good parameters / workaround to broken hardware.

If you say, that you already know all of this anyway upfront and your filesystem is specific for a given platform, then use tmpfs for /etc/bluetooth/main.conf or alternatively, we actually introduce support for CONFIGURATION_DIRECTORY. We already have this in iwd and it would make sense to just support it.

The CONFIGURATION_DIRECTORY directory comes from systemd (, but since it is just an environment variable for the bluetoothd process, you can do with any shell by just setting it.



  parent reply	other threads:[~2022-03-10  9:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-07 18:57 [RFC] Bluetooth: Adding support for /etc/bluetooth/main.conf.d Katherine Lai
2022-03-08 10:14 ` Bastien Nocera
2022-03-08 22:50   ` Sonny Sasaka
2022-03-09  9:17     ` Bastien Nocera
2022-03-09 17:05       ` Sonny Sasaka
2022-03-09 20:44       ` Luiz Augusto von Dentz
2022-03-09 21:02         ` Luiz Augusto von Dentz
2022-03-09 23:34           ` Sonny Sasaka
2022-03-10  9:51 ` Marcel Holtmann [this message]
2022-03-10 18:30   ` Sonny Sasaka
2022-03-10 20:04     ` Marcel Holtmann
2022-03-18 20:13       ` Sonny Sasaka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.