On Wed, 2020-12-09 at 20:04 +0100, Laurent Vivier wrote: > 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: Sigh. No, it's not a bug, it's just that the cups tool was never ported from the bluez 4.x to the current bluez 5.x API... Until that's ported (if ever, given the low number of Bluetooth printers around...), you could try to extract the IEEE1284 ID using: sdptool records DC:0D:30:90:23:C7 But I'm not certain that this working is necessary to actually try a print. Have you tested that?
