Bug in SH1106brzo.h I2C data transfer

[rob040]

Describe the bug
The BRZO version of the SH1106 implementation cannot work, just from code inspection.

This code part from

       brzo_i2c_start_transaction(this->_address, BRZO_I2C_SPEED);

       for (y = minBoundY; y <= maxBoundY; y++) {
         sendCommand(0xB0 + y);
         sendCommand(minBoundXp2H);
         sendCommand(minBoundXp2L);
         for (x = minBoundX; x <= maxBoundX; x++) {
             k++;
             sendBuffer[k] = buffer[x + y * displayWidth];
             if (k == 16)  {
               brzo_i2c_write(sendBuffer, 17, true);
               k = 0;
             }
         }
         if (k != 0) {
           brzo_i2c_write(sendBuffer, k + 1, true);
           k = 0;
         }
         yield();
       }
       if (k != 0) {
         brzo_i2c_write(sendBuffer, k + 1, true);
       }
       brzo_i2c_end_transaction();

Above you see a start I2C data transmission brzo_i2c_start_transaction before sending 3 I2C commands, which each do a start send 3 bytes and end, and then perform the data transmissions brzo_i2c_write() and final brzo_i2c_end_transaction.

This never could have worked.

I have not tested it myself because I have no interest in the brzo I2C driver, which is supposedly written in ESP Assembly, when the Arduino Wire uses the hardware I2C peripheral.

Also, the SH1106 has a number of commands from the SSD1306 not implemented or not specified but still are being send. Only one implementation (out of 3) where there is a different init and setContrast method.
Besides that, the fact that the I2C bus clock is much higher than the specs allow, the bus is being overclocked by factor 2 to 2.5, without doing a basic signal integrity check and putting any requirements on the required OC pull-ups, is not smart, to say it kindly.
IMHO the library should play it safe; the user can, if he wants, go wild and overclock the i2c bus.

When comparing the 7 different variants of interface and the two different display chips, it bugs me that there are functional differences that should not be there.

I leave it up to the maintainer to cleanup the unneeded differences, the signed vs unsigned variables, the incomplete geometry support, inconsistencies in argument types, naming, and coding style in general and decide what unity his library should show. One small example, why use tree variants of macro min(), _min(), std::min()?