Received-SPF: pass (google.com: domain of linux-bluetooth-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18;
From:   Laurent Vivier <laurent@vivier.eu>
Subject: Re: Bluetooth printer connection error
To:     Bastien Nocera <hadess@hadess.net>, linux-bluetooth@vger.kernel.org
References: <3a6fa942-bec5-5e5f-391d-197d1c1eafa6@vivier.eu>
 <e885258a0b9a3ba15640553e9f002cdfc89f4b79.camel@hadess.net>
 <73236e71-781f-1dea-13d5-61fdc45d5e13@vivier.eu>
 <0eeb1a4a1254d00b2d1a8f77133af4d16857b266.camel@hadess.net>
Message-ID: <ab6ae9d9-9104-5454-d93d-b734c0eb9eba@vivier.eu>
Date:   Wed, 9 Dec 2020 20:04:51 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101
 Thunderbird/78.5.0
MIME-Version: 1.0
In-Reply-To: <0eeb1a4a1254d00b2d1a8f77133af4d16857b266.camel@hadess.net>
Content-Type: text/plain; charset=utf-8
Content-Language: fr
Content-Transfer-Encoding: 8bit
Precedence: bulk

Le 09/12/2020 à 12:34, Bastien Nocera a écrit :
> On Wed, 2020-12-09 at 12:14 +0100, Laurent Vivier wrote:
...
>>> If the printer has uses the SPP or HCRP printing profiles, you
>>> should
>>> see it when using:
>>> /usr/lib/cups/backend/bluetooth
>>> without any arguments.
>>
>> As I don't see it once it is paired, I guess it is not using one of
>> these profiles.
> 
> I don't remember how this used to work, but you'll probably only see
> something if the printer is visible.
> 
> You might be able to get the printer to work by adding:
> bluetooth://DC0D309023C7
> as a printer in the printer settings of your favourite desktop
> environment, if it actually uses SPP.
> 
> running the cups backend with:
> /usr/lib/cups/backend/bluetooth --get-deviceid bluetooth://DC0D309023C7
> 
> should show you whether it can get autoconfigured for CUPS use.
> 

Thank you Bastien, it's exactly what I needed to know.

Correct me if I'm wrong but it seems there is a bug in the cups/bluetooth
command:

profiles/cups/main.c

602 static gboolean print_ieee1284(const char *bdaddr)
...
616         message = dbus_message_new_method_call("org.bluez", "/",
617                         "org.bluez.Manager",
618                         "DefaultAdapter");
619
620         adapter_reply = dbus_connection_send_with_reply_and_block(conn,
621                         message, -1, NULL);

adapter_reply is always NULL.

I can see following errors with dbus-monitor:

method call time=1607536119.751900 sender=:1.194 -> destination=org.bluez serial=2 path=/;
interface=org.bluez.Manager; member=DefaultAdapter
error time=1607536119.752107 sender=:1.71 -> destination=:1.194
error_name=org.freedesktop.DBus.Error.UnknownMethod reply_serial=2
   string "Method "DefaultAdapter" with signature "" on interface "org.bluez.Manager" doesn't exist
"

And I can find a commit removing calls to org.bluez.Manager:

commit 86a7b07c22f3a595ba3c48092359287905bf0878
Author: Mikel Astiz <mikel.astiz@bmw-carit.de>
Date:   Wed Dec 5 13:51:34 2012 +0100

    dbus: Remove org.bluez.Manager

    After the decision to drop the "default-adapter" feature in the D-Bus
    API, the org.bluez.Manager interface can be entirely dropped since it
    has been replaced by the ObjectManager.


What did I miss?

Thanks,
Laurent