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

RasPi Framebuffer assignment #749

Closed
okyeron opened this issue Mar 11, 2019 · 3 comments
Closed

RasPi Framebuffer assignment #749

okyeron opened this issue Mar 11, 2019 · 3 comments
Assignees

Comments

@okyeron
Copy link
Contributor

@okyeron okyeron commented Mar 11, 2019

In building norns on Raspberry Pi I've run into this issue:

With a Pi 3b+ the onboard HDMI seems to want framebuffer fb0. So with my DAC board/hat which uses the same OLED display - I've had to recompile norns screen.c to use fb1 for the OLED.

I recently found this reference:

Application software that uses the frame buffer device (e.g. the X server) will use /dev/fb0 by default (older software uses /dev/fb0current). You can specify an alternative frame buffer device by setting the environment variable $FRAMEBUFFER to the path name of a frame buffer device, e.g. (for sh/bash users):

export FRAMEBUFFER=/dev/fb1

So perhaps it would be possible to have screen.c reference $FRAMEBUFFER - and then set an environment variable in the norns startup scripts - instead of hard coding fb0?

@tehn
Copy link
Member

@tehn tehn commented Mar 11, 2019

we could also just have the fb be a command line arg passed to matron, which defaults to fb0.

i'd prefer to avoid more environment setup if possible. but i suppose if $FRAMEBUFFER isn't available we also just use fb0?

@ngwese
Copy link
Member

@ngwese ngwese commented Mar 18, 2019

i agree with the notion that if matron and co are going to become more configurable that it is done via explicit command line arguments (with the current values as default) as opposed to environment variables.

@okyeron
Copy link
Contributor Author

@okyeron okyeron commented Mar 29, 2019

Addressed with #783

@okyeron okyeron closed this Mar 29, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants