Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add struct for coordinates in disp_dev API #14051

Closed
wants to merge 3 commits into from

Conversation

Citrullin
Copy link
Contributor

Contribution description

In order to simplify the API and reduce the amount of parameters, I changed the disp_dev API to use a struct to store the coordinates. I also changed the ili9341 driver to make us of it.

Testing procedure

Haven't tried the tests yet. Just checked for compile errors and warnings.
Changed tests are available in tests/disp_dev and driver_ili9341

@aabadie
Copy link
Contributor

aabadie commented May 10, 2020

I don't think that changing the ili9341 driver is also required (even if convenient). And you forgot to update the call to disp_dev in the lvgl package.

@Citrullin
Copy link
Contributor Author

Citrullin commented May 10, 2020

I don't think that changing the ili9341 driver is also required (even if convenient). And you forgot to update the call to disp_dev in the lvgl package.

True, not necessary. Maybe, we even want to keep the old API for backwards compatibility. Not sure, if there anyone is using it.
Okay, I will take a look into the lvgl package.

@bergzand
Copy link
Member

There is ongoing discussion on how to represent coördinates and colors in RIOT in #13787. I think we should first come to a conclusion there before further modifying the API here.

@Citrullin
Copy link
Contributor Author

There is ongoing discussion on how to represent coördinates and colors in RIOT in #13787. I think we should first come to a conclusion there before further modifying the API here.

Ohh, haven't seen this issue. Yes, I had the same issue, so I added it to the API. Consider it as proposal then. Will create a PR with reference to it.

@miri64 miri64 added Area: drivers Area: Device drivers Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. labels Jul 2, 2020
@stale
Copy link

stale bot commented Jan 6, 2021

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Jan 6, 2021
@Citrullin
Copy link
Contributor Author

"State: don't stale" Still an open topic

@stale stale bot removed the State: stale State: The issue / PR has no activity for >185 days label Jan 6, 2021
Copy link
Contributor

@aabadie aabadie left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The changes in the ili9341 driver implementation are not needed. Only the adaption layer to disp_dev needs to map the x1,y1,x2,y2 coordinates to the coordinate struct of disp_dev.

Also, please rebase!

Comment on lines +47 to +56
/**
* @brief Type to store the update coordinates in
*/
typedef struct {
uint16_t x1; /**< Left coordinate */
uint16_t x2; /**< Right coordinate */
uint16_t y1; /**< Top coordinate */
uint16_t y2; /**< Bottom coordinate */
} disp_dev_coordinates_t;

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There's no need to change the driver API. Just the disp_dev API needs the be changed and the ili9341 adapter functions can handle the conversion.
This will keep this PR minimal and avoid an API change (for something that is not marked as experimental, the ili9341 driver).

Copy link
Contributor Author

@Citrullin Citrullin Feb 23, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, fair enough. But why shouldn't I touch this as well? So I can reduce the amount of arguments there as well? To get to the ideal of 3/4 arguments for a function.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why shouldn't I touch this as well? So I can reduce the amount of arguments there as well?

The PR title says that it touches the disp_dev API, the underlying display driver doesn't have to be changed. This keeps the PR focused on the disp_dev changes and this eases and speeds up the reviews.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Okay, fair enough. But why shouldn't I touch this as well? So I can reduce the amount of arguments there as well? To get to the ideal of 3/4 arguments for a function.

@Citrullin could you split the ili9341 changes into another PR? It can be based on this one, that way everyone is happy (I think :) )

uint16_t x1, uint16_t x2, uint16_t y1, uint16_t y2,
const uint16_t *color)
void disp_dev_map(disp_dev_t *dev, disp_dev_coordinates_t *coordinates,
const uint16_t *color)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
const uint16_t *color)
const uint16_t *color)

@MrKevinWeiss MrKevinWeiss added this to the Release 2021.07 milestone Jun 22, 2021
@MrKevinWeiss MrKevinWeiss removed this from the Release 2021.07 milestone Jul 15, 2021
@stale
Copy link

stale bot commented Mar 2, 2022

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.

@stale stale bot added the State: stale State: The issue / PR has no activity for >185 days label Mar 2, 2022
@stale stale bot closed this Apr 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area: drivers Area: Device drivers Process: API change Integration Process: PR contains or issue proposes an API change. Should be handled with care. State: stale State: The issue / PR has no activity for >185 days Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants