Hi Johan, Am 04.01.20 um 14:18 schrieb Johan Hedberg: > Hi Stefan, > > On 4. Jan 2020, at 13.45, Stefan Seyfried <stefan.seyfried@xxxxxxxxxxxxxx> wrote: >>> This would be for creating a "rfcomm service" for other devices to >>> connect to, right? (The equivalent of "rfcomm listen...") >>> >>> But how would I connect e.g. to my serial module (I got this for trying >>> it by myself instead of relying on bugreporters results...), so what's >>> the dbus equivalent of "rfcomm connect hci0 <bdaddr> <channel>"? >> >> OK, now I found https://github.com/tonyespy/bluez5-spp-example which >> explains how to do this. >> >> I'd still think an example in the bluez documentation would be useful, >> because… > > Doesn’t test/test-profile give a pretty good overview of both server- and client-role usage of the Profile D-Bus API? You are right, now that I know what I am looking for, this is exactly the example code that I need ;-) > The main difference to the RFCOMM ioctls is that instead of a TTY you get a file descriptor (which I guess you could convert to a TTY using a pty). For client, another difference is that it’s a two-step process, i.e. first you register the client role profile and then you call e.g. ConnectProfile (which test-profile doesn’t cover). I'll try to cook up an example application (if I get some spare time...) for the (apparently) #1 wanted application of old rfcomm: connecting to a "serial console" via bluetooth and then starting a terminal program on /dev/rfcomm0 This should be possible by either providing a local socket that can be connected to or a pty. We can then decide if we include this in the bluez examples or if I provide it as a separate project. Best regards ans thanks for the info, Stefan -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman
