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 fullscreen feature and pixel formatting fix #6

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

LinusCDE
Copy link
Owner

Adding fullscreen (just landscape without any controls, size is the same for now).

Also noticed that mapping pixels was wrong. I turned 2 grayscale value into one rgb565 which is now how that works. Somehow I never noticed. The approach to map the pixels should not impact performance at all.

Not sure about making fullscreen any larger though. The size is just not enough to justify another dithermap (8x instead of 4x). Scaling the dithered image might work, but would add a lot of extra cpu overhead and the bigger image in general might also hurt performance on top (maybe not on the rM 1, not sure). So not sure if it would be even worth it.

Binary for commit c6761f9: doomarkable.zip

Fullscreen can be accessed from the settings and the user gets informed on how to exit again and that he should have a keyboard present.

@Eeems do you think this would work? I think #2 would be done then.

The conversion was faulty and resulted in wrong values.

Not sure why I never noticed it.
@Eeems
Copy link

Eeems commented Jan 26, 2024

So this doesn't automatically detect a connected keyboard?

@LinusCDE
Copy link
Owner Author

Not right now, but I could add that. What does the name of the folio contain? I wouldn't like to do it automatically for every keyboard as people might be confused why it happens otherwise.

@Eeems
Copy link

Eeems commented Jan 27, 2024

Not right now, but I could add that. What does the name of the folio contain? I wouldn't like to do it automatically for every keyboard as people might be confused why it happens otherwise.

You can detect if the pogo is connected by querying /sys/pogo/status/pogo_connected. It will return 1 when the pogo port is connected, and 0 when it's not connected. You can also check /sys/pogo/status/lang to see what keyboard language it is, just in case you want to provide different keyboard layouts.

I haven't checked to see if there is an easy way to poll this for changes, it's probably better to poll for changes to /dev/input to dynamically detect if the folio is connected.

For making sure that it's the folio, under /sys/class/input/event*/ you can expect the following (in 3.3.2 at least):

  • device/name: rM_Keyboard
  • device/phys: pogo/input0
  • device/id/vendor: 2edd
  • device/id/product: 001

There also seems to be something interesting under /sys/pogo/emulation:
image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants