add a way to have only one oled display on split kbs

[oresk]

When there is only one display on split keyboards,
there is a lag on the half that does not have the display.
That produces a lot of frustration especially for new,
less experienced users.

This commit allows to disable the display on one side,
without disabling the oled driver completely.

By defining OLED_NO_DISPLAY_ON_MASTER or
OLED_NO_DISPLAY_ON_SLAVE we disable the oled display.

This closes #9060

Description

Types of Changes

• Core
• Bugfix
• New feature
• Enhancement/optimization
• Keyboard (addition or update)
• Keymap/layout/userspace (addition or update)
• Documentation

Issues Fixed or Closed by This PR

#9060
*

Checklist

• My code follows the code style of this project: C, Python
• I have read the PR Checklist document and have made the appropriate changes.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes.
• I have tested the changes and verified that they work and don't break anything (as well as I can manage).

[oresk]

I'm not sure I'm a fan of this.

IIRC, @zvecr may have had a solution that prevents the lag (which can/will happen on both halves, IIRC), overall.

Additionally, boards like the ErgoDox EZ actually has some handling that will check for i2c errors, and prevent it from "spamming" i2c commands when it can't find the device. I think that may be a better way to handle this, rather than defines.
Especially, as ... what if you use EE_HANDS with a split, and change what side is plugged in? Then these settings are now useless.

Could you point me in the direction of the EZ code that handles the i2c errors (I'm still finding my way round the project), for sure that code should be general and a part of the core, right?

[drashna]

Could you point me in the direction of the EZ code that handles the i2c errors (I'm still finding my way round the project), for sure that code should be general and a part of the core, right?

Not a problem, at all!

qmk_firmware/keyboards/ergodox_ez/matrix.c

Lines 113 to 129 in c9eaf1a

	if (mcp23018_status) { // if there was an error
	if (++mcp23018_reset_loop == 0) {
	// if (++mcp23018_reset_loop >= 1300) {
	// since mcp23018_reset_loop is 8 bit - we'll try to reset once in 255 matrix scans
	// this will be approx bit more frequent than once per second
	print("trying to reset mcp23018\n");
	mcp23018_status = init_mcp23018();
	if (mcp23018_status) {
	print("left side not responding\n");
	} else {
	print("left side attached\n");
	ergodox_blink_all_leds();
	#ifdef RGB_MATRIX_ENABLE
	rgb_matrix_init(); // re-init driver on reconnect
	#endif
	}
	}

And if you notice, basically every time the ergodox's matrix reads from i2c it updates mcp23018_status (which is an i2c port expanded).

[tzarc]

Could this take into account the new function added in #10382 ?

[drashna]

Sorry for the delay!
The ErgoDox EZ saves the status for all of the i2c calls, and if there is an error, it has to run a certain number of loops (255, by default) before it tries to re-init the controller.

qmk_firmware/keyboards/ergodox_ez/matrix.c

Lines 82 to 96 in 6ad813e

	if (mcp23018_status) { // if there was an error
	if (++mcp23018_reset_loop == 0) {
	print("trying to reset mcp23018\n");
	mcp23018_status = init_mcp23018();
	if (mcp23018_status) {
	print("left side not responding\n");
	} else {
	print("left side attached\n");
	ergodox_blink_all_leds();
	#ifdef RGB_MATRIX_ENABLE
	rgb_matrix_init(); // re-init driver on reconnect
	#endif
	}
	}
	}

Also, if there is an error, it avoids running scans until the status has been reset.

qmk_firmware/keyboards/ergodox_ez/matrix.c

Lines 143 to 144 in 6ad813e

	if (mcp23018_status) { // if there was an error
	return 0;

This prevents it from trying to run the i2c commands every cycle, which can have a 10-100ms timeout (which is what causes the slowdown).

[drashna]

This should be resolved by #11129