New M110S not recognized and not requiring the 1mm left margin

[mtorromeo]

Hi,
thanks for the driver.

I have just received a new M110S printer and, first of all, I have to specify that I needed to modify the driver to make it recognize my printer. After that, I noticed a weird offset in the printed labels, and it was caused by the hardcoded 1mm left margin in the printer definition.

Both the bluetooth name-matching logic and the usb vid:pid did not match my printer.

I don't know if somehow I got a fake clone, but it looks legit to me, and the android app had no issue recognizing the printer and printing perfectly centered labels.

The vid:pid pair of my device is 0483:5740 and the bluetooth name, which is also displayed on the printer screen, is Q199E5797220037.

This is the device details when connected via USB:

❯ lsusb -v -d 0483:5740

Bus 003 Device 004: ID 0483:5740 STMicroelectronics Virtual COM Port
Negotiated speed: Full Speed (12Mbps)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0483 STMicroelectronics
  idProduct          0x5740 Virtual COM Port
  bcdDevice            1.00
  iManufacturer           1 Jieli Technology
  iProduct                2 USB Composite Device
  iSerial                 3 1234567890ABCDEF
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x0020
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0x80
      (Bus Powered)
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         7 Printer
      bInterfaceSubClass      1 Printer
      bInterfaceProtocol      2 Bidirectional
      iInterface              4 (error)
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               1
Device Status:     0x0000
  (Bus Powered)

The serial in particular is very weird.

To make it work I changed the driver and added a new matching logic for bluetooth using this regex ^(Mr\.in(.*)|Q[0-9]{3}[A-Z][0-9]{10}|T02)$ and an extra check on properties.get('Icon', None) != 'printer', and looked for usb I just looked for the new vid:pid.

I then created a new drv and called it M110S without the 1mm margin and everything works fine.

I can create an MR with all the fixes, but I am not really sure about discriminating the driver by calling it M110S, and I don't really know how else to call it.

[mtorromeo]

I forgot to say the reported FW version is 2.2.3 and that could also be a factor.

[daig0rian]

I bought my Phomemo M110 around the time of this pull request (#5), which would be around February 2023.

In my case, the firmware version of the device is v1.0.1, which appears to be considerably older than the one you are using.
Despite this, the Vendor ID / Device ID is the same (0483:5740). Based on this observation, using this VID:PID pair for M110 seems reasonable, at least for older units like mine.

However, it also appears that this VID:PID is reused by other devices. If that is the case, relying solely on the USB ID for automatic model detection might be insufficient.
This suggests that some form of additional communication or probing over USB may be needed to distinguish models more reliably, similar to what is in this commit:
cbc0e97

Regarding Bluetooth, I was not able to obtain explicit model information from the Bluetooth metadata available to me.
That said, the Bluetooth class information bits do appear to correctly indicate an imaging device. From my perspective, using the class information itself may be more reliable than relying on the derived icon, although this is based only on my limited testing.

For reference, below are some command outputs from my Phomemo M110 (FW v1.0.1):

$ lsusb -v -d 0483:5740

Bus 001 Device 002: ID 0483:5740 STMicroelectronics Virtual COM Port
Couldn't open device, some information will be missing
Negotiated speed: Full Speed (12Mbps)
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 [unknown]
  bDeviceSubClass         0 [unknown]
  bDeviceProtocol         0 
  bMaxPacketSize0        64
  idVendor           0x0483 STMicroelectronics
  idProduct          0x5740 Virtual COM Port
  bcdDevice            2.00
  iManufacturer           1 QUIN
  iProduct                2 QUIN Printer
  iSerial                 3 P0V00000011N
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength       0x005b
    bNumInterfaces          3
    bConfigurationValue     1
    iConfiguration          0 
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              400mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass         7 Printer
      bInterfaceSubClass      1 Printer
      bInterfaceProtocol      2 Bidirectional
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x01  EP 1 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
    Interface Association:
      bLength                 8
      bDescriptorType        11
      bFirstInterface         1
      bInterfaceCount         2
      bFunctionClass          2 Communications
      bFunctionSubClass       2 Abstract (modem)
      bFunctionProtocol       0 
      iFunction               0 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           0
      bInterfaceClass         2 Communications
      bInterfaceSubClass      2 Abstract (modem)
      bInterfaceProtocol      1 AT-commands (v.25ter)
      iInterface              0 
      CDC Header:
        bcdCDC               1.10
      CDC Call Management:
        bmCapabilities       0x03
          call management
          use DataInterface
        bDataInterface          1
      CDC ACM:
        bmCapabilities       0x02
          line coding and serial state
      CDC Union:
        bMasterInterface        0
        bSlaveInterface         1 
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        2
      bAlternateSetting       0
      bNumEndpoints           2
      bInterfaceClass        10 CDC Data
      bInterfaceSubClass      0 [unknown]
      bInterfaceProtocol      0 
      iInterface              0 
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x02  EP 2 OUT
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            2
          Transfer Type            Bulk
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0040  1x 64 bytes
        bInterval               0

$ bluetoothctl info DC:0D:30:C2:CB:C5
Device DC:0D:30:C2:CB:C5 (public)
	Name: Q192J27K0480025
	Alias: Q192J27K0480025
	Class: 0x00040680 (263808)
	Icon: printer
	Paired: yes
	Bonded: yes
	Trusted: no
	Blocked: no
	Connected: no
	LegacyPairing: no
	UUID: Serial Port               (00001101-0000-1000-8000-00805f9b34fb)
	UUID: Unknown                   (0000ff00-0000-1000-8000-00805f9b34fb)
	ManufacturerData.Key: 0x0000 (0)
	ManufacturerData.Value:
  dc 0d 30 c2 cb c5                                ..0...          
	AdvertisingFlags:
  0a         

$ sdptool search SP
Inquiring ...
Searching for SP on DC:0D:30:C2:CB:C5 ...
Service Name: SPP Dev
Service RecHandle: 0x10001
Service Class ID List:
  "Serial Port" (0x1101)
Protocol Descriptor List:
  "L2CAP" (0x0100)
  "RFCOMM" (0x0003)
    Channel: 1
Language Base Attr List:
  code_ISO639: 0x656e
  encoding:    0x6a
  base_offset: 0x100

[daig0rian]

One additional observation from my side:
On Windows, my Phomemo M110 (Feb 2023, FW V1.0.1) is reported as “M110S” by the OS. From this behavior, adding support under M110S also seems reasonable.
If you end up creating a PR, I would be happy to test it on my device and share the results.