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

Support folio input #2

Open
Eeems opened this issue Jan 13, 2024 · 4 comments
Open

Support folio input #2

Eeems opened this issue Jan 13, 2024 · 4 comments

Comments

@Eeems
Copy link

Eeems commented Jan 13, 2024

I haven't tested, but I assume folio input doesn't work?

@Eeems
Copy link
Author

Eeems commented Jan 16, 2024

It looks like generic keyboards are not supported. Adding generic evdev keyboard support would be really helpful. Along with rotating the display and hiding the on-screen keys when a physical keyboard (like the folio) is detected.

@LinusCDE
Copy link
Owner

Will need to see if I find the time to add it. Adding EV-Dev support in general sounds fun. Not sure how I would handle the roation. The size of the would likely need to stay the same though as otherwise it would increase the Runtime-Memory-Footprint by a lot (the dithering uses a 30 MB lookup table for the current target resolution).

Would it even make sense anyway? The game runs horribly on the rM 2 anyway and I don't recommend it at all. Or can the folio also be connected to the rM 1? I think connecting a keyboard was at least possible using instructions from Keywriter. I could try to make it work like they do and test against the rM 1 for it.

@Eeems
Copy link
Author

Eeems commented Jan 16, 2024

I think it would be worth it for anybody connecting a keyboard to the rM1 as well. You just need to detect a connected physical keyboard device and rotate the screen if there is one, and unrotate if there isn't. I have code in oxide underway to do this, but it is very much dependent on rMs epaper QPA to indicate if a device was added or removed. The rest of it should be reusable, although I need to sort out a better way to ignore virtual keyboards (keyd for example)

https://github.com/Eeems-Org/oxide/blob/master/shared%2Fliboxide%2Fdevicesettings.cpp#L226-L296

@LinusCDE
Copy link
Owner

LinusCDE commented Jan 20, 2024

Will try to implement these as two saperate things:

  • EVKeyboard(s) support
  • Add option for "Fullscreen"

Fullscreen makes more sense, since I designed the UI with the Idea that it always has the fixed amount of space below the game area. Rotating or moving it would mean a lot of rework for that layout system. It's probably easiest then to treat rotates as a fullscreen mode, where no UI (except maybe a custom close button) will be shown.

I can also check if it's worth to include 2 dithering maps (the current one, + another one for fullscreen (bigger)). If I'm not mistaken the fullscreen one will likely take up 350 MB of ram once loaded. Not sure how big it will be inside the binary file. The current one is around 350 KiB compressed with zstd.

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

No branches or pull requests

2 participants