drivers: display: Add display_clear function

[rruuaanng]

from #12937

vanwinkeljan:
It is suggested that a new API should be introduced to clear the display screen, rather than misusing display_set_contrast.

cc @vanwinkeljan

I believe this makes sense for application developers. Sometimes, when implementing screen clearing, I have to write functions that send raw messages, so I prefer to leave the implementation to the driver vendors rather than the users.

[fabiobaltieri]

nit: this would fit in 80 columns, unwrap?

[rruuaanng]

In order to synchronize the code style of other functions, I have to do this (maybe I can take this opportunity to tidy up their style.

static inline int display_read(const struct device *dev, const uint16_t x,
			       const uint16_t y,
			       const struct display_buffer_descriptor *desc,
			       void *buf)
{
	struct display_driver_api *api =
		(struct display_driver_api *)dev->api;

	if (api->read == NULL) {
		return -ENOSYS;
	}

	return api->read(dev, x, y, desc, buf);
}

[soburi]

Although it is simply called "clear," its behavior is not uniquely determined.
It would be better to make it more clear.
For example, setting memory to 0 (in this case, the colors will be inverted for MONO01 and MONO10), making the screen black...
Perhaps it would be better to call the action of filling the entire screen with a specific color "clear" (It makes it easier to keep the behavior unique, so I prefer this.).

[soburi]

Because of these difficulties, I think including a reference implementation with SDL in this PR would be a good idea.

[rruuaanng]

For example, setting memory to 0 (in this case, the colors will be inverted for MONO01 and MONO10), making the screen black...

The default clearing behavior can be defined as filling the screen with solid black(I think)—unless inversion is enabled, in which case it would be white. In other words, I believe this should be determined by the driver implementer. If they consider the "default" state of the screen to be white or any other color, that should be acceptable.

Because of these difficulties, I think including a reference implementation with SDL in this PR would be a good idea.

I believe display_sdl.c is an appropriate position.

[soburi]

When designing a HAL, it is necessary to find a "greatest common denominator" that allows uniform behavior on any hardware and is compatible with many hardware devices.
This is also the valuable benefit of using Zephyr.
Therefore, "depends on implementation" is a kind of resignation, and the design must avoid this.