ddvk / remarkable2-framebuffer

remarkable2 framebuffer reversing
MIT License
276 stars 22 forks source link

Add support for release 2.9 #65

Closed matteodelabre closed 3 years ago

matteodelabre commented 3 years ago

This PR replaces our existing strategies for dynamically locating the various functions we need to make rm2fb work with a static lookup table of the addresses of these functions.

We’re making this choice because it seems that we’re spending more time trying to adapt the strategies after each release than we would if we just updated a static list of addresses. This change also gives us the opportunity to check that rm2fb works correctly with an OS release before users get to use it. The cost is that we’ll need to make an update after each OS release.

To test, you’ll need to move the offsets file in the src/ folder to /opt/share/rm2fb/offsets on the tablet (the parent directory needs to be created).

raisjn commented 3 years ago

thank you for making this diff! the approach seems reasonable - it seems like we can get updates for a release done within a week or so using this one (assuming that someone knowledgeable will be able to add the signatures).

my pieces of feedback are:

  1. what will the process for adding new signatures be? committing to toltec or this repo?
  2. should the server statically compile in known signatures (so we don't need an extra file) and allow overrides via text file? (or is this too much work?)
  3. we will need to add some docs to this repo (minimal is fine) about this new file or make an issue and link to it (so people can find more info)
matteodelabre commented 3 years ago

Thanks for the feedback!

  1. what will the process for adding new signatures be? committing to toltec or this repo?

I’d say it’s best to keep the signatures in this repo so that those who don’t use Toltec can still install and use rm2fb fairly easily.

  1. should the server statically compile in known signatures (so we don't need an extra file) and allow overrides via text file? (or is this too much work?)

Yeah it would make sense to bundle signatures in the binary, especially for manual installs. It shouldn’t be too hard to accomplish, I’ll look into it.

  1. we will need to add some docs to this repo (minimal is fine) about this new file or make an issue and link to it (so people can find more info)

Yes, good point! I’ll look into it too.

matteodelabre commented 3 years ago

Tested on versions 2.8 and 2.9 beta.

hunt529 commented 3 years ago

@matteodelabre -- I am not a developer but I am a user of Remarkable2 + KO Reader (which fully depends on rm2fb) and your continued updating/efforts. I just wanted to express appreciation for what you are doing.

I recently upgraded to 2.9 beta -- and am looking forward to getting my KO Reader back :)

matteodelabre commented 3 years ago

Hi @hunt529! Of course, as you may know, I’m not the only one working on rm2fb. But thank you for your support, and I’m glad you find the project useful!

@raisjn Do you think we can merge this?

matteodelabre commented 3 years ago

@raisjn Yep, updateType is used to select between the two possible signatures of the update function, since its signature was changed from void (*)(int, int, int, int, int, int) to void (*)(QRect&, int, int) in release 2.9 beta.