progress on porting frameworks and apps

[raisjn]

Some frameworks in use around the rM1 community for building apps:

framework	lang	status	apps	notes
libremarkable	rust	finished	retris, chessmarkable, plato, whiteboard
remarkable.NET	C#	not started
rmkit	cpp	finished	harmony, mines, remux
qtsgepaper	cpp+qt	finished	calculator, draft, oxide, wikipedia, keywriter, chess2
koreader base	cpp+lua	finished	koreader

Apps that have been tested:

• retris
• plato
• koreader
• mines
• chess2
• remux
• oxide
• calculator
• draft
• retris
• chessmarkable
• plato
• whiteboard

Apps to test:

• anything remaining in toltec

[Ameb]

I'll reference this issue on the "awesome" list. Thanks!

[KashMoneyMillionaire]

What would work on the remarkable.NET port for RM2 look like?

[Eeems]

That would be a great question for @parzivail

[parzivail]

My father just received his RM2 in the mail this week so I'll have the opportunity to play around with it and see what needs to be changed while I'm home for Thanksgiving. I apologize for the lack of activity on rM.NET recently, life has definitely gotten in the way.

[raisjn]

To upgrade an rM1 app for rM2 compatibility, there are a few things that need to be done: #13

[parzivail]

Looks good. The way I handled inputs for rM.NET didn't hardcode eventX names (those can change if you boot with a USB device plugged in, like a keyboard, for example) so it looks like I just need to add an entry for the new battery device (I already have framework in place for targeting multiple device generations) and figure out what all this new framebuffer business is about

[parzivail]

rM.NET just writes directly to /dev/fb0 so theoretically there doesn't need to be any change there, correct? If so I think apps built with rM.NET should work natively with the RM2 with the exception of the battery API

Edit: unless the ioctl commands changed for screen refreshing, then I need to update those as well

[raisjn]

the way the framebuffer works has significantly changed on the rm2. this repo, rm2fb, provides an automatic translation layer that lets an rm1 app draw to screen without code changes (using an ldpreload shim)

[parzivail]

Got it. I was referring to the fact that drawing to the screen likely hasn't changed -- the framebuffer format has been a standard in Linux for quite some time -- but the actual process of refreshing the e-ink display (hence ioctl) is what changed?

[ddvk]

drawing has changed, this is not the framebuffer you know,

but you will find out yourself

[parzivail]

Alright, after becoming more educated on the topic I concede that I am a dumbass.

[Hultner]

Would it be inhibitly difficult to get a terminal working?
Having CLI access on the RM2 would be a dream for me, so I could ssh to my laptop, attach my tmux+vi sessions and use the rink screen for work. Not sure of this is way out there when it comes to what's feasible in the near future.

[danshick]

Would it be inhibitly difficult to get a terminal working?
Having CLI access on the RM2 would be a dream for me, so I could ssh to my laptop, attach my tmux+vi sessions and use the rink screen for work. Not sure of this is way out there when it comes to what's feasible in the near future.

There's a working implementation of fingerterm in Toltec.

[fenollp]

libremarkable apps: whiteboard

I published a new version on toltec, it works :)