Branch: refs/heads/974231 Home: https://github.com/bluez/bluez Commit: 514701a0867a9c478d6f50e203fb16f14b46580e https://github.com/bluez/bluez/commit/514701a0867a9c478d6f50e203fb16f14b46580e Author: Andrew Sayers <kernel.org@xxxxxxxxxxxxxxx> Date: 2025-06-20 (Fri, 20 Jun 2025) Changed paths: M obexd/client/driver.c M obexd/client/driver.h M obexd/client/pbap.c M obexd/plugins/bluetooth.c M obexd/src/logind.c M obexd/src/logind.h M obexd/src/main.c M obexd/src/transport.c M obexd/src/transport.h Log Message: ----------- Refactor uid_state handling We talked recently about refactoring logind.{c,h} to fit more neatly into the program's wider architecture. This patch sketches out a possible approach. It compiles, but has not been tested beyond that. If I'm on the right track, I'll come back with a proper solution. The old API provided callbacks on high-level "init" and "exit" events. That made sense for the limited case it was used for, but seems unlikely to scale if this starts picking up more use cases. So the RFC API just provides a single event that passes a `logind_cb_context` struct to callbacks, and provides `LOGIND_USER_IS_ACTIVE(ctxt)` to replicate the old behaviour. The old API invited individual transports/drivers to use it directly, which again made sense for version 1, but bypassed `transport.h` and `driver.h`. The RFC API registers callbacks with `driver.h` and `transport.h` in a more normal way, and they pass `logind_cb_context` straight through to the callbacks. That means we won't need to do much refactoring if the struct changes some day, but also means individual transports/drivers need to know about `logind.h`. The alternative would look something like this: To unsubscribe from these emails, change your notification settings at https://github.com/bluez/bluez/settings/notifications
