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

Expose OLED buffer to userspace functions #8595

Closed
1 of 4 tasks
brickbots opened this issue Mar 29, 2020 · 7 comments
Closed
1 of 4 tasks

Expose OLED buffer to userspace functions #8595

brickbots opened this issue Mar 29, 2020 · 7 comments
Labels
enhancement help wanted stale Issues or pull requests that have become inactive without resolution.

Comments

@brickbots
Copy link
Contributor

Feature Request Type

  • Core functionality
  • Add-on hardware support (eg. audio, RGB, OLED screen, etc.)
  • Alteration (enhancement/optimization) of existing feature(s)
  • New behavior

Description

With recent changes to the OLED driver to enable raw buffer writing, I'd like to be able to read the current OLED buffer from user space code. This will enable more sophisticated visualization routines in user space and I am seeking advice on the safest, most QMK-like way to do this.

I can think of at least two ways to enable read access to the OLED buffer from keymaps or user space code:

  • Declare the buffer in oled_driver.h as extern, enabling a redefinition in other code files
  • Provide a function in oled_driver.c to provide either a copy of, or pointer to, the buffer

I've played with both and settled on the extern solution in my own test branch, but before issuing a pull request for this change, I wanted to check with some smarter folks on the ramifications of either approach.

Thank you for any advice on the best way to implement this.

@mtei
Copy link
Contributor

mtei commented Apr 25, 2020

Tagging @XScorpion2

@XScorpion2
Copy link
Contributor

XScorpion2 commented Apr 25, 2020

I think extern is the wrong approach to go about this as then the name of the buffer is now fixed, and cannot be changed if necessary due to collision. (which it probably will, I kinda named it generically)

Initial thought (no coffee yet): maybe a function that takes some optional parameters, such as position you want to retrieve, then returns a pointer to that buffer location & size remaining in the buffer.

@mtei
Copy link
Contributor

mtei commented Apr 25, 2020

@XScorpion2, See also #8777.

@XScorpion2
Copy link
Contributor

@mtei can I get coffee first? =D

@stale
Copy link

stale bot commented Jul 24, 2020

This issue has been automatically marked as stale because it has not had activity in the last 90 days. It will be closed in the next 30 days unless it is tagged properly or other activity occurs.
For maintainers: Please label with bug, in progress, on hold, discussion or to do to prevent the issue from being re-flagged.

@stale stale bot added the stale Issues or pull requests that have become inactive without resolution. label Jul 24, 2020
@stale
Copy link

stale bot commented Aug 23, 2020

This issue has been automatically closed because it has not had activity in the last 30 days. If this issue is still valid, re-open the issue and let us know.

@stale stale bot closed this as completed Aug 23, 2020
@brickbots
Copy link
Contributor Author

Just a note for anyone following along at home, a merge request to address this #8777 has been merged into the development branch and should be universally available when this branch becomes the master.

Thanks everyone for your help on this one!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement help wanted stale Issues or pull requests that have become inactive without resolution.
Projects
None yet
Development

No branches or pull requests

3 participants