Push upstream?

[Eeems]

Do you intend to push this upstream?

[LinusCDE]

Sorry for the late response, apparently one does not watch a fork by default, so I was never notified.

I'm not sure if this would be wanted or feasable atm. Many changes sometimes "hack" the code to make it work and some parts were reworked and would need readjustment to work with Kobo devices again.

With enough work, it would probably be possible and I really wanted it at the start. Plato seems to be primarily or rather only targeted at Kobo devices (as a matter of fact, "reMarkable X" is just a model and get's displayed as "Kobo reMarkable X").

So I'm not really sure if it would be worth the effort. Given some time, I can definitely try a less intrusive re-port since I gained a lot more knowledge since then.

[LinusCDE]

I think this should be a doable thing. I think I would have the time the following days / weeks to work on this.

@baskerville Currently my workflow of just merging upstream changes and fixing conflicts while sometimes annoying works usually pretty okay. Would you be willing to have this then pushed upstream in a PR? Otherwise I think the effort would not be worth it for myself.

Below a proposal how the changes could be made non-destructively to the upstream project.

Proposed Roadmap for re-implemenation of reMarkable support and current modifications

I would renaming the current master to old-master and sync master with the current upstream branch to re-implement the changes in a non-destructible fashion.

Also a lot of extra files can be removed. For example the files make_remarkable.sh and .cargo/config are not really required. oxide and oxide-icon.png can be moved to the package recipe directory in toltec. For changes in shell scripts, code similar to this can be used to detect a reMarkable and its model.

For adding the code / modifications, I would add a feature called remarkable. With this feature I would:

• Enable the otherwise disabled/optional dependency libremarkable
• Enable the pub mod for framebuffer/remarkable.rs
• Add settings to the main menu and disables unsupported features
• Add the reMarkable model to device.rs
• Add the RemarkableSettings struct to the yaml config for those features
• Use an alternate input implementation to use rotation values given by libremarkable or uses major changes parts in related functions (this could be simpler, but I would need to understand the rotation values in devices.rs better. maybe translate libremarkable's rotation values into those. For now I would probably just use an alternate implementation like currently.
• Maybe some changes to the start-up and other scripts in contrib
• Other similar things I forgot

Those things would be implemented using conditional compilation which can look roughly like this:

enum SomeEnum {
    ModelA,
    ModelB,
    #[cfg(feature = "remarkable")]
    Remarkable,
}

// or

fn handle_input() {
    // original input code
    #[cfg(feature = "remarkable")]
    {
        // some remarkable specific code that e.g. uses libremarkable
    }
    #[cfg(not(feature = "remarkable"))] // aka else
        // original code that is supposed to not be here for the remarkable
    }
    // more original input code
}

Future update-flow possibilities

Testing for reMarkable would not need to be made on the upstream project if you don't want (or just check a cargo check works with it, a generic armv7 cross-compiler is enough). I could pull new changes, test them on both reMarkable models and then create a PR to toltec update the package recipe. This could even be done automatically from the upstream project by another person, as someone there needs to do a quick review / test of the package anyway before merging (probably even myself if I don't create the PR).

The easiest thing would be though to just me from time to time, syncing the upstream master (no more merging needed) and create a new corresponding release and push the new version to toltec myself. So highly flexible but there is no need to change anything here and put the releasing for reMarkable on you, baskerville or other members doing the work on upstream for the kobo devices.

Edit: fixed missing / broken links.