search

LinusCDE / doomarkable

DOOM on the reMarkable
GNU General Public License v2.0
38 stars 0 forks source link

Support folio input #2

Open Eeems opened 8 months ago

Eeems commented 8 months ago

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

Eeems commented 8 months ago

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 commented 8 months ago

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 commented 8 months ago

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 commented 7 months ago

Will try to implement these as two saperate things:

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.