reMarkable 2 support #15

fedecupe · 2020-11-09T09:56:41Z

Hi there,
Any hope for remarkable 2 support?

Thanks for your work.

matteodelabre · 2020-11-09T16:21:05Z

Interacting with the screen of the reMarkable 2 turns out to be considerably harder than with the reMarkable 1, since it is not exposed as a Linux framebuffer device. There is an ongoing reverse-engineering effort to achieve that in the https://github.com/ddvk/remarkable2-framebuffer repository. Once it stabilizes and we have enough people able to test it on their rM2 tablets (which I don’t currently own), I’ll be happy to work on integrating it into VNSee!

fedecupe · 2020-11-09T18:02:49Z

Thanks, if you need some debug I have the rm2 and have a Linux Box.

LeifAndersen · 2020-12-27T02:47:07Z

For what its worth I've actually gotten this to work on the remarkable2, using the remarkable2-framebuffer repo.

https://www.youtube.com/watch?v=X0_6_c_1kBE&feature=youtu.be

LeifAndersen · 2020-12-27T02:48:57Z

Obviously the refresh rate is to slow to watch a video....but for reading websites it works pretty great.

ennioVisco · 2020-12-28T15:41:46Z

For what its worth I've actually gotten this to work on the remarkable2, using the remarkable2-framebuffer repo.

https://www.youtube.com/watch?v=X0_6_c_1kBE&feature=youtu.be

Any changes, or it works just out of the box?

LeifAndersen · 2020-12-28T15:53:11Z

I did not need to modify vnsee or remarkable2-framebuffer. But I did compile both of them myself using the rm2 sdk.

Basically, I opened up two shells over ssh. First I shut down xochitl:

systemctl stop xochitl

Then, in the first shell I ran:

LD_PRELOAD="./dist/librm2fb_server.so.1.0.0" /usr/bin/remarkable-shutdown

Then, I started a vnc server on my desktop:

x11vnc -repeat -forever -nocursor -allow 10.11.99.1 -nopw -geometry 1872x1404 -rotate -90

Finally, in the second shell I ran:

LD_PRELOAD="./dist/librm2fb_client.so.1.0.0" ./vnsee

Equator11111 · 2020-12-30T20:38:03Z

This worked for me as well. However I was unable to get input working (both from pen and touch). Is this something that will still have to be reworked for the RM2 or is there something that I am missing?

LeifAndersen · 2020-12-31T03:33:09Z

Very strange. I'm also noticing the same behaviour, which is odd since the rm2 seems to use similar input to the rm1. Maybe its possible you hard-coded some device ids that changed?

I'll have to look into this more this weekend.

NickHu · 2021-01-04T16:07:47Z

It's probably this Eeems-Org/oxide#48 (comment)

o- · 2021-01-29T13:55:07Z

It's probably this Eeems-Org/oxide#48 (comment)

I tried to just change these inputs and compile. It's going in the right direction, though there is more to it. It seems the resulting cursor location is quite off. And I can scroll down, but not up :)

matteodelabre · 2021-01-29T17:06:20Z

Thanks all for your input! I’ve recently acquired a rM2 and I’m currently working on adding rM2 support.

matteodelabre · 2021-02-10T14:30:04Z

Hello everyone, I’m glad to announce that rM2 support has reached a beta state. Here’s a development build for those of you who would like to test it: vnsee-rm2-beta-018b42.zip. (You can also build it from the rm2-support branch if you’d like to inspect the source by yourself.)

Some notes:

You’ll need a working install of the remarkable2-framebuffer project for VNSee to work. You can install it easily from Toltec. If you see the error message below, you have launched VNSee without a running rm2fb server:

Error: (rmioc::screen_rm2fb) Open shared memory framebuffer: No such file or directory

You do not need to launch vnsee with LD_PRELOAD="…/librm2fb_client.so.1.0.0" vnsee or rm2fb-client vnsee, just type ./vnsee directly.
The VNC server that you connect to must have a resolution of 1404x1872, instead of 1408x1872 (this is due to differences in the underlying screen buffer). This difference will be fixed in reMarkable resolution is 1404×1872 but this client forces servers to send a 1408×1872 image #11.
The full refresh option, triggered by pressing the home key on the reMarkable 1, is not available since there is no such key on the reMarkable 2. This will probably be implemented later on through a touch gesture.

If you test this beta build, please feel free to share any remarks or bugs in this thread and I’ll make sure to address them.

kunalb · 2021-02-10T22:06:42Z

Just to confirm, did you mean that the resolution should be 1404x1872?

At the moment I get an error of failing to initialize the VNC connection after it tries for several seconds.

matteodelabre · 2021-02-10T22:10:45Z

Just to confirm, did you mean that the resolution should be 1404x1872?

Yup, thanks! I fixed it.

At the moment I get an error of failing to initialize the VNC connection after it tries for several seconds.

Is your VNC server running on port 5900?

kunalb · 2021-02-10T22:12:50Z

Yup -- the x11vnc output explicitly prints out PORT=5900.

matteodelabre · 2021-02-10T22:15:36Z

Is there any output from x11vnc when you start vnsee?

kunalb · 2021-02-10T22:36:50Z

No, nothing from x11vnc. I'm not quite sure how to debug further. I can try building locally and messing around with it this weekend.

matteodelabre · 2021-02-10T22:45:56Z

If there’s no output from x11vnc then it looks like a mismatch between the VNC server’s address and what address VNSee is trying to reach. When you start VNSee, you should see a first message saying Connecting to 10.11.99.x:5900…. Can you check that your computer’s IP on the USB network (which can be seen in the output of ip addr) matches with what VNSee shows?

fedecupe · 2021-02-11T11:42:45Z

Hi, I get this error when trying to launch vnsee on remarkable2

reMarkable: ~/ ./vnsee
Connecting to 10.11.99.4:5900...
terminate called after throwing an instance of 'std::runtime_error'
  what():  Server uses an unsupported resolution (1408x1872). This client can only cope with a screen width of exactly 260 pixels and a screen height of 23936 pixels
Aborted (core dumped)

matteodelabre · 2021-02-11T12:09:38Z

Hi! Thanks for the report. Could you please check whether cat /sys/devices/soc0/machine reports reMarkable 2.0? Also, just to be sure, could you double-check that you’re running the dev build and not an old one? (sha256sum vnsee should print the following hash: 35138600893ef76f5775ec263704f811341e2e4c31b915da9602e323392d98fe)

kunalb · 2021-02-11T13:57:47Z

Hmm, ip addr gives me the right addresses and things look to be sane on both sides. (10.11.99.2)
But I can't actually hit any port from the remarkable to the laptop: I tried to telnet into the vnc server, just to see if it worked and remove a variable and that didn't work. I also tried to hit an http server on my laptop from remarkable and that also failed.
telnet'ing into the vnc server from my laptop (just to make sure that bit was correct) does show a connection attempt on x11vnc.
ping works.

matteodelabre · 2021-02-11T14:15:26Z

Can you check whether you have an iptables rule filtering inbound traffic on the USB network interface? Is there any output from dmesg -w on your computer when you attempt to telnet from the rM?

kunalb · 2021-02-11T14:40:10Z

Looks like it's iptables rule filtering set up for my office laptop; looking into that now! Thank you for pointing me to that!
dmesg -w didn't have any output.

kunalb · 2021-02-11T14:53:07Z

All right, forcefully ACCEPTING packets from USB let me start connecting! With that in place, I now get an error for

reMarkable: ~/ ./vnsee
Connecting to 10.11.99.2:5900...
terminate called after throwing an instance of 'std::runtime_error'
  what():  Server uses an unsupported resolution (1408x1872). This client can only cope with a screen width of exactly 1404 pixels and a screen height of 1872 pixels
Aborted (core dumped)

maybe because of

gtf 1404 1872 60

  # 1408x1872 @ 60.00 Hz (GTF) hsync: 116.22 kHz; pclk: 225.00 MHz
  Modeline "1408x1872_60.00"  225.00  1408 1520 1672 1936  1872 1873 1876 1937  -HSync +Vsync

I haven't dug into this before; should I manually try replacing 1408 by 1404 while creating the new mode?

matteodelabre · 2021-02-11T15:42:49Z

All right, forcefully ACCEPTING packets from USB let me start connecting!

Great!

I haven't dug into this before; should I manually try replacing 1408 by 1404 while creating the new mode?

gtf automatically rounds arguments to be a multiple of 8 it seems. Actually we don’t really need to bother with the hsync/vsync arguments of the modeline since it’s a virtual output, so you could simply use:

xrandr --newmode 1404x1872 0 1404 1404 1404 1404 1872 1872 1872 1872

I’ll update the docs accordingly.

kunalb · 2021-02-11T15:47:25Z

Keeping the 1408 and only changing the clip on VNC let me start things working! I'll try with the simpler mode definition as well, thank you so much! I'm typing this out on the remarkable screen now.

Edit: touch, etc. seems to work perfectly well.

Changed rm2fb Made rm2-suspend-fix rm2-only Apps that do not support reMarkable 2: - appmarkable (LinusCDE/appmarkable#2) - rmservewacominput (because it depends on appmarkable) - vnsee (matteodelabre/vnsee#15) - whiteboard-hypercard (fenollp/reMarkable-tools#12) Apps updated to include the rM2 shim: - calculator - chessmarkable - draft - fingerterm - keywriter - koreader (through setting LD_PRELOAD in the existing wrapper script) - oxide (also changed the package to build from source) - plato - recrossable - remarkable-splash - retris - rmkit - xochitl (created a wrapper script at /opt/bin/xochitl) - zshelf

This PR improves Toltec’s support for reMarkable 2 in a few ways: * Prevents users from installing packages that are known to be incompatible with their device (fixes #129). * Automatically installs and sets up the rm2fb server when an app that uses the framebuffer is installed. * Stops relying on LD_PRELOAD to load the rm2fb shim into apps that need it. Instead, change their dynamic dependencies to include the shim directly. Thanks to this change, we no longer need to set LD_PRELOAD globally (fixes #248) and users can launch apps that need the shim without prefixing them with `rm2fb-client`. Tooling changes (more details in the updated docs/package.md): * Added the `archs` field for declaring which device(s) a recipe is compatible with. Supported values are `rmall` (for device-independent packages), `rm1` (for reMarkable 1) and `rm2` (for reMarkable 2). When multiple arch values are set for a recipe, the recipe is generated once per entry, which allows specializing builds for specific devices. * Replaced the `depends` field with an `installdepends` field used for declaring install-time dependencies. Previously, dependencies declared in the `depends` field were fulfilled both at build time and at install time, with no way of declaring install-time-only dependencies. * Added a `replaces` field that sets the `Replaces` value in the generated package. Used for migrating users from the `rm2fb` package to the `display` and `rm2fb-shim` packages (see below). * Changed [the web package listing](https://toltec-dev.org/dev/split-architectures) to include download links for each available architecture of each package. * Packages are now stored in subdirectories named after their architecture. This is because opkg does not like seeing packages for architectures other than the ones it is configured to accept in opkg.conf. With this layout change, we can make opkg happy by only adding subdirectories for enabled architectures. Install changes: * The bootstrap script now adds the `rmall` architecture (and folder) on all installs, and the `rm1` or `rm2` architecture (and folder) depending on the type of the device it’s executed on. It will fail if the device is not of a recognized type (based on the value of `/sys/devices/soc0/machine`). * Running the new bootstrap script on an existing install will upgrade the configuration to use the new architecture subdirectories layout. rm2fb changes: * The package is split into two packages, `display` (which provides the rm2fb server on rM2 and is an empty package on rM1) and `rm2fb-shim` (which provides the client shim on rM2 and a mock shim on rM1). * The `rm2fb-server` command is removed (the most common use-case being that the display server is started from the systemd unit). * The `rm2fb-client` command is renamed to `rm2fb-shim`, with the expectation that users will not need it anymore, unless for development purposes. Apps marked as reMarkable-1-only: * appmarkable (LinusCDE/appmarkable#2) * rmservewacominput (because it depends on appmarkable) * vnsee (matteodelabre/vnsee#15) * whiteboard-hypercard (fenollp/reMarkable-tools#12) Apps marked as reMarkable-2-only: * rm2-suspend-fix Apps updated to include the rM2 shim: * calculator * chessmarkable * draft * fingerterm * keywriter * koreader (through setting LD_PRELOAD in the existing wrapper script) * oxide * plato * recrossable * remarkable-splash * retris * rmkit * xochitl (through a new wrapper script at /opt/bin/xochitl) * zshelf Test plan (on rM1 and rM2): * Starting from a clean stable or testing install of Toltec, download the updated bootstrap script and run: ```console $ toltec_branch=dev/split-architectures bash bootstrap ``` * This should update the `/opt/etc/opkg.conf` configuration file to enable the `rmall` architecture and, depending on the device you’re running this on, the `rm1` or the `rm2` architecture. * It should also replace the `src/gz toltec` line with two source lines, `src/gz toltec-rmall` and `src/gz toltec-rm1` or `src/gz toltec-rm2`, pointing to subfolders of `https://toltec-dev.org/dev/split-architectures`. * Run `opkg upgrade`. Most installed packages should get upgraded, and if you had installed any packages that use the screen, the `display` and `rm2fb-shim` packages should get installed. If you previously installed the `rm2fb` package, it should get removed automatically. * Try installing `rm2-suspend-fix` on a reMarkable 1, or `vnsee` on a reMarkable 2: both operations should fail. * Test all updated packages to make sure they can properly draw to the screen (both on rM1 and rM2) and that you can interact with them through the touchscreen and the pen, when applicable. * In particular, make sure that apps work properly when launched from draft, oxide or remux.

This PR improves Toltec’s support for reMarkable 2 in a few ways: * Prevents users from installing packages that are known to be incompatible with their device (fixes #129). * Automatically installs and sets up the rm2fb server when an app that uses the framebuffer is installed. * Stops relying on LD_PRELOAD to load the rm2fb shim into apps that need it. Instead, change their dynamic dependencies to include the shim directly. Thanks to this change, we no longer need to set LD_PRELOAD globally (fixes #248) and users can launch apps that need the shim without prefixing them with `rm2fb-client`. Tooling changes (more details in the updated docs/package.md): * Added the `archs` field for declaring which device(s) a recipe is compatible with. Supported values are `rmall` (for device-independent packages), `rm1` (for reMarkable 1) and `rm2` (for reMarkable 2). When multiple arch values are set for a recipe, the recipe is generated once per entry, which allows specializing builds for specific devices. * Replaced the `depends` field with an `installdepends` field used for declaring install-time dependencies. Previously, dependencies declared in the `depends` field were fulfilled both at build time and at install time, with no way of declaring install-time-only dependencies. * Added a `replaces` field that sets the `Replaces` value in the generated package. Used for migrating users from the `rm2fb` package to the `display` and `rm2fb-shim` packages (see below). * Changed [the web package listing](https://toltec-dev.org/dev/split-architectures) to include download links for each available architecture of each package. * Packages are now stored in subdirectories named after their architecture. This is because opkg does not like seeing packages for architectures other than the ones it is configured to accept in opkg.conf. With this layout change, we can make opkg happy by only adding subdirectories for enabled architectures. Install changes: * The bootstrap script now adds the `rmall` architecture (and folder) on all installs, and the `rm1` or `rm2` architecture (and folder) depending on the type of the device it’s executed on. It will fail if the device is not of a recognized type (based on the value of `/sys/devices/soc0/machine`). * Running the new bootstrap script on an existing install will upgrade the configuration to use the new architecture subdirectories layout. rm2fb changes: * The package is split into two packages, `display` (which provides the rm2fb server on rM2 and is an empty package on rM1) and `rm2fb-shim` (which provides the client shim on rM2 and a mock shim on rM1). * The `rm2fb-server` command is removed (the most common use-case being that the display server is started from the systemd unit). * The `rm2fb-client` command is renamed to `rm2fb-shim`, with the expectation that users will not need it anymore, unless for development purposes. Apps marked as reMarkable-1-only: * appmarkable (LinusCDE/appmarkable#2) * rmservewacominput (because it depends on appmarkable) * vnsee (matteodelabre/vnsee#15) * whiteboard-hypercard (fenollp/reMarkable-tools#12) Apps marked as reMarkable-2-only: * rm2-suspend-fix Apps updated to include the rM2 shim: * calculator * chessmarkable * draft * fingerterm * keywriter * koreader (through setting LD_PRELOAD in the existing wrapper script) * oxide * plato * recrossable * remarkable-splash * retris * rmkit * xochitl (through a new wrapper script at /opt/bin/xochitl) * zshelf Test plan (on rM1 and rM2): * Starting from a clean stable or testing install of Toltec, download the updated bootstrap script and run: ```console $ toltec_branch=dev/split-architectures bash bootstrap ``` * This should update the `/opt/etc/opkg.conf` configuration file to enable the `rmall` architecture and, depending on the device you’re running this on, the `rm1` or the `rm2` architecture. * It should also replace the `src/gz toltec` line with two source lines, `src/gz toltec-rmall` and `src/gz toltec-rm1` or `src/gz toltec-rm2`, pointing to subfolders of `https://toltec-dev.org/dev/split-architectures`. * Run `opkg upgrade`. Most installed packages should get upgraded, and if you had installed any packages that use the screen, the `display` and `rm2fb-shim` packages should get installed. If you previously installed the `rm2fb` package, it should get removed automatically. * Try installing `rm2-suspend-fix` on a reMarkable 1, or `vnsee` on a reMarkable 2: both operations should fail. * Test all updated packages to make sure they can properly draw to the screen (both on rM1 and rM2) and that you can interact with them through the touchscreen and the pen, when applicable. * In particular, make sure that apps work properly when launched from draft, oxide or remux (some issues remain with oxide and remux).

Baccanno · 2021-03-13T14:28:31Z

[Edit] Regardless or the rotation issue on windows TightVNC, this works well now as stated in #13 thank you so much.

So used the https://github.com/matteodelabre/vnsee/files/5961668/vnsee-rm2-beta-018b42.zip after having toltec installed rm2fb and I manage to reach this step

./vnsee
Connecting to 10.11.99.2:5900...
Error: Failed to initialize VNC connection

I believe I time out (after 1min or so) because nothing connects to it. I'm on windows and I'll have to look into available VNC servers.

matteodelabre · 2021-03-14T23:02:32Z

Thanks for testing @Baccanno! I will be publishing a release including rM2 support soon (probably in the coming week).

This PR improves Toltec’s support for reMarkable 2 in a few ways: * Prevents users from installing packages that are known to be incompatible with their device (fixes #129). * Automatically installs and sets up the rm2fb server when an app that uses the framebuffer is installed. * Stops relying on LD_PRELOAD to load the rm2fb shim into apps that need it. Instead, change their dynamic dependencies to include the shim directly. Thanks to this change, we no longer need to set LD_PRELOAD globally (fixes #248) and users can launch apps that need the shim without prefixing them with `rm2fb-client`. It replaces the previous PR #136. #### Tooling changes More details in the updated [docs/package.md](https://github.com/toltec-dev/toltec/blob/tooling/split-architectures/docs/package.md). * Added the `archs` field for declaring which device(s) a recipe is compatible with. Supported values are `rmall` (for device-independent packages), `rm1` (for reMarkable 1) and `rm2` (for reMarkable 2). When multiple arch values are set for a recipe, the recipe is generated once per entry, which allows specializing builds for specific devices. * Replaced the `depends` field with an `installdepends` field used for declaring install-time dependencies. Previously, dependencies declared in the `depends` field were fulfilled both at build time and at install time, with no way of declaring install-time-only dependencies. * Added a `replaces` field that sets the `Replaces` value in the generated package. Used for migrating users from the `rm2fb` package to the `display` and `rm2fb-client` packages (see below). * Added a `patch_rm2fb` flag for recipes to instruct the build system to patch all the generated binaries that use the rM1 framebuffer with the rm2fb client shim. * Changed [the web package listing](https://toltec-dev.org/dev/split-architectures) to include download links for each available architecture of each package. * Packages are now stored in subdirectories named after their architecture. This is because opkg does not like seeing packages for architectures other than the ones it is configured to accept in opkg.conf. With this layout change, we can make opkg happy by only adding subdirectories for enabled architectures. #### Install changes * The bootstrap script now adds the `rmall` architecture (and folder) on all installs, and the `rm1` or `rm2` architecture (and folder) depending on the type of the device it’s executed on. It will fail if the device is not of a recognized type (based on the value of `/sys/devices/soc0/machine`). * Running the new bootstrap script on an existing install will upgrade the configuration to use the new architecture subdirectories layout. #### rm2fb changes * The package is split into two packages, `display` (which provides the rm2fb server on rM2 and is an empty package on rM1) and `rm2fb-client` (which provides the client shim on rM2 and a mock shim on rM1). * The `rm2fb-server` command is removed (the most common use-case being that the display server is started from the systemd unit). #### Apps changes Apps marked as reMarkable-1-only: * vnsee (matteodelabre/vnsee#15) * whiteboard-hypercard (fenollp/reMarkable-tools#12) Apps marked as reMarkable-2-only: * rm2-suspend-fix Apps updated to include the rM2 shim: * appmarkable * calculator * chessmarkable * draft * fingerterm * keywriter * koreader (through setting LD_PRELOAD in the existing wrapper script) * oxide * plato * recrossable * remarkable-splash * retris * rmkit * wikipedia * xochitl (through a new wrapper script at /opt/bin/xochitl) * zshelf #### Test plan On rM1 and rM2 (system version: 2.5). * Starting from a clean install of Toltec stable or testing, download the updated bootstrap script and run: ```console $ toltec_branch=dev/split-architectures bash bootstrap ``` * This should update the `/opt/etc/opkg.conf` configuration file to enable the `rmall` architecture and, depending on the device you’re running this on, the `rm1` or the `rm2` architecture. * It should also replace the `src/gz toltec` line with two source lines, `src/gz toltec-rmall` and `src/gz toltec-rm1` or `src/gz toltec-rm2`, pointing to subfolders of `https://toltec-dev.org/dev/split-architectures`. * Run `opkg upgrade`. Most installed packages should get upgraded, and if you had installed any packages that use the screen, the `display` and `rm2fb-client` packages should get installed. If you previously installed the `rm2fb` package, it should get removed automatically. * Try installing `rm2-suspend-fix` on a reMarkable 1, or `vnsee` on a reMarkable 2: both operations should fail. * Test all updated packages to make sure they can properly draw to the screen (both on rM1 and rM2) and that you can interact with them through the touchscreen and the pen, when applicable. It is no longer needed to prefix each app invocation with `rm2fb-client` on the command line on reMarkable 2. * In particular, make sure that apps work properly when launched from draft, oxide or remux (things to check: launching, pausing, killing apps, switching back and forth from xochitl). #### Rollout plan When this PR hits testing and stable, existing users will no longer receive updates until they run the new bootstrap script on their existing installs. They will also probably see an error when they do `opkg update`. Figuring out how to automatic transition users is left to a future PR. Co-authored-by: okay <okay@arkose>

lapwat · 2021-04-14T13:33:26Z

Workaround instructions

Mono display

@LeifAndersen instructions work great

Multiple displays landscape mode

# host shell
wget https://github.com/ddvk/remarkable2-framebuffer/releases/download/v0.0.3/librm2fb_client.so.1.0.0
wget https://github.com/ddvk/remarkable2-framebuffer/releases/download/v0.0.3/librm2fb_server.so.1.0.0
scp librm2fb_client.so.1.0.0 root@$REMARKABLE_IP:dist # dist directory should exist
scp librm2fb_server.so.1.0.0 root@$REMARKABLE_IP:dist # dist directory should exist

xrandr --newmode 1872x1404 0 1872 1872 1872 1872 1404 1404 1404 1404
xrandr --addmode VIRTUAL1 1872x1404
xrandr --output VIRTUAL1 --mode 1872x1404 --right-of eDP1
x11vnc -repeat -forever -nocursor -allow $REMARKABLE_IP -nopw -clip 1872x1404+1920+0% -rotate -90

# remarkable shell
systemctl stop xochitl
LD_PRELOAD="./dist/librm2fb_server.so.1.0.0" /usr/bin/remarkable-shutdown
LD_PRELOAD="./dist/librm2fb_client.so.1.0.0" ./vnsee

matteodelabre · 2021-04-24T20:40:15Z

Just released version 0.4.0 with support for reMarkable 2. Thanks to everyone who provided feedback on the development build!

This PR improves Toltec’s support for reMarkable 2 in a few ways: * Prevents users from installing packages that are known to be incompatible with their device (fixes toltec-dev#129). * Automatically installs and sets up the rm2fb server when an app that uses the framebuffer is installed. * Stops relying on LD_PRELOAD to load the rm2fb shim into apps that need it. Instead, change their dynamic dependencies to include the shim directly. Thanks to this change, we no longer need to set LD_PRELOAD globally (fixes toltec-dev#248) and users can launch apps that need the shim without prefixing them with `rm2fb-client`. It replaces the previous PR toltec-dev#136. #### Tooling changes More details in the updated [docs/package.md](https://github.com/toltec-dev/toltec/blob/tooling/split-architectures/docs/package.md). * Added the `archs` field for declaring which device(s) a recipe is compatible with. Supported values are `rmall` (for device-independent packages), `rm1` (for reMarkable 1) and `rm2` (for reMarkable 2). When multiple arch values are set for a recipe, the recipe is generated once per entry, which allows specializing builds for specific devices. * Replaced the `depends` field with an `installdepends` field used for declaring install-time dependencies. Previously, dependencies declared in the `depends` field were fulfilled both at build time and at install time, with no way of declaring install-time-only dependencies. * Added a `replaces` field that sets the `Replaces` value in the generated package. Used for migrating users from the `rm2fb` package to the `display` and `rm2fb-client` packages (see below). * Added a `patch_rm2fb` flag for recipes to instruct the build system to patch all the generated binaries that use the rM1 framebuffer with the rm2fb client shim. * Changed [the web package listing](https://toltec-dev.org/dev/split-architectures) to include download links for each available architecture of each package. * Packages are now stored in subdirectories named after their architecture. This is because opkg does not like seeing packages for architectures other than the ones it is configured to accept in opkg.conf. With this layout change, we can make opkg happy by only adding subdirectories for enabled architectures. #### Install changes * The bootstrap script now adds the `rmall` architecture (and folder) on all installs, and the `rm1` or `rm2` architecture (and folder) depending on the type of the device it’s executed on. It will fail if the device is not of a recognized type (based on the value of `/sys/devices/soc0/machine`). * Running the new bootstrap script on an existing install will upgrade the configuration to use the new architecture subdirectories layout. #### rm2fb changes * The package is split into two packages, `display` (which provides the rm2fb server on rM2 and is an empty package on rM1) and `rm2fb-client` (which provides the client shim on rM2 and a mock shim on rM1). * The `rm2fb-server` command is removed (the most common use-case being that the display server is started from the systemd unit). #### Apps changes Apps marked as reMarkable-1-only: * vnsee (matteodelabre/vnsee#15) * whiteboard-hypercard (fenollp/reMarkable-tools#12) Apps marked as reMarkable-2-only: * rm2-suspend-fix Apps updated to include the rM2 shim: * appmarkable * calculator * chessmarkable * draft * fingerterm * keywriter * koreader (through setting LD_PRELOAD in the existing wrapper script) * oxide * plato * recrossable * remarkable-splash * retris * rmkit * wikipedia * xochitl (through a new wrapper script at /opt/bin/xochitl) * zshelf #### Test plan On rM1 and rM2 (system version: 2.5). * Starting from a clean install of Toltec stable or testing, download the updated bootstrap script and run: ```console $ toltec_branch=dev/split-architectures bash bootstrap ``` * This should update the `/opt/etc/opkg.conf` configuration file to enable the `rmall` architecture and, depending on the device you’re running this on, the `rm1` or the `rm2` architecture. * It should also replace the `src/gz toltec` line with two source lines, `src/gz toltec-rmall` and `src/gz toltec-rm1` or `src/gz toltec-rm2`, pointing to subfolders of `https://toltec-dev.org/dev/split-architectures`. * Run `opkg upgrade`. Most installed packages should get upgraded, and if you had installed any packages that use the screen, the `display` and `rm2fb-client` packages should get installed. If you previously installed the `rm2fb` package, it should get removed automatically. * Try installing `rm2-suspend-fix` on a reMarkable 1, or `vnsee` on a reMarkable 2: both operations should fail. * Test all updated packages to make sure they can properly draw to the screen (both on rM1 and rM2) and that you can interact with them through the touchscreen and the pen, when applicable. It is no longer needed to prefix each app invocation with `rm2fb-client` on the command line on reMarkable 2. * In particular, make sure that apps work properly when launched from draft, oxide or remux (things to check: launching, pausing, killing apps, switching back and forth from xochitl). #### Rollout plan When this PR hits testing and stable, existing users will no longer receive updates until they run the new bootstrap script on their existing installs. They will also probably see an error when they do `opkg update`. Figuring out how to automatic transition users is left to a future PR. Co-authored-by: okay <okay@arkose>

This PR improves Toltec’s support for reMarkable 2 in a few ways: * Prevents users from installing packages that are known to be incompatible with their device (fixes #129). * Automatically installs and sets up the rm2fb server when an app that uses the framebuffer is installed. * Stops relying on LD_PRELOAD to load the rm2fb shim into apps that need it. Instead, change their dynamic dependencies to include the shim directly. Thanks to this change, we no longer need to set LD_PRELOAD globally (fixes #248) and users can launch apps that need the shim without prefixing them with `rm2fb-client`. It replaces the previous PR #136. #### Tooling changes More details in the updated [docs/package.md](https://github.com/toltec-dev/toltec/blob/tooling/split-architectures/docs/package.md). * Added the `archs` field for declaring which device(s) a recipe is compatible with. Supported values are `rmall` (for device-independent packages), `rm1` (for reMarkable 1) and `rm2` (for reMarkable 2). When multiple arch values are set for a recipe, the recipe is generated once per entry, which allows specializing builds for specific devices. * Replaced the `depends` field with an `installdepends` field used for declaring install-time dependencies. Previously, dependencies declared in the `depends` field were fulfilled both at build time and at install time, with no way of declaring install-time-only dependencies. * Added a `replaces` field that sets the `Replaces` value in the generated package. Used for migrating users from the `rm2fb` package to the `display` and `rm2fb-client` packages (see below). * Added a `patch_rm2fb` flag for recipes to instruct the build system to patch all the generated binaries that use the rM1 framebuffer with the rm2fb client shim. * Changed [the web package listing](https://toltec-dev.org/dev/split-architectures) to include download links for each available architecture of each package. * Packages are now stored in subdirectories named after their architecture. This is because opkg does not like seeing packages for architectures other than the ones it is configured to accept in opkg.conf. With this layout change, we can make opkg happy by only adding subdirectories for enabled architectures. #### Install changes * The bootstrap script now adds the `rmall` architecture (and folder) on all installs, and the `rm1` or `rm2` architecture (and folder) depending on the type of the device it’s executed on. It will fail if the device is not of a recognized type (based on the value of `/sys/devices/soc0/machine`). * Running the new bootstrap script on an existing install will upgrade the configuration to use the new architecture subdirectories layout. #### rm2fb changes * The package is split into two packages, `display` (which provides the rm2fb server on rM2 and is an empty package on rM1) and `rm2fb-client` (which provides the client shim on rM2 and a mock shim on rM1). * The `rm2fb-server` command is removed (the most common use-case being that the display server is started from the systemd unit). #### Apps changes Apps marked as reMarkable-1-only: * vnsee (matteodelabre/vnsee#15) * whiteboard-hypercard (fenollp/reMarkable-tools#12) Apps marked as reMarkable-2-only: * rm2-suspend-fix Apps updated to include the rM2 shim: * appmarkable * calculator * chessmarkable * draft * fingerterm * keywriter * koreader (through setting LD_PRELOAD in the existing wrapper script) * oxide * plato * recrossable * remarkable-splash * retris * rmkit * wikipedia * xochitl (through a new wrapper script at /opt/bin/xochitl) * zshelf #### Test plan On rM1 and rM2 (system version: 2.5). * Starting from a clean install of Toltec stable or testing, download the updated bootstrap script and run: ```console $ toltec_branch=dev/split-architectures bash bootstrap ``` * This should update the `/opt/etc/opkg.conf` configuration file to enable the `rmall` architecture and, depending on the device you’re running this on, the `rm1` or the `rm2` architecture. * It should also replace the `src/gz toltec` line with two source lines, `src/gz toltec-rmall` and `src/gz toltec-rm1` or `src/gz toltec-rm2`, pointing to subfolders of `https://toltec-dev.org/dev/split-architectures`. * Run `opkg upgrade`. Most installed packages should get upgraded, and if you had installed any packages that use the screen, the `display` and `rm2fb-client` packages should get installed. If you previously installed the `rm2fb` package, it should get removed automatically. * Try installing `rm2-suspend-fix` on a reMarkable 1, or `vnsee` on a reMarkable 2: both operations should fail. * Test all updated packages to make sure they can properly draw to the screen (both on rM1 and rM2) and that you can interact with them through the touchscreen and the pen, when applicable. It is no longer needed to prefix each app invocation with `rm2fb-client` on the command line on reMarkable 2. * In particular, make sure that apps work properly when launched from draft, oxide or remux (things to check: launching, pausing, killing apps, switching back and forth from xochitl). #### Rollout plan When this PR hits testing and stable, existing users will no longer receive updates until they run the new bootstrap script on their existing installs. They will also probably see an error when they do `opkg update`. Figuring out how to automatic transition users is left to a future PR. Co-authored-by: okay <okay@arkose>

matteodelabre added the enhancement New feature or request label Nov 9, 2020

matteodelabre pinned this issue Nov 9, 2020

ennioVisco mentioned this issue Dec 4, 2020

Windows Support #13

Open

matteodelabre changed the title ~~Remarkable 2 support~~ reMarkable 2 support Jan 28, 2021

This comment has been minimized.

Sign in to view

matteodelabre unpinned this issue Feb 11, 2021

matteodelabre mentioned this issue Feb 20, 2021

macOS support #21

Open

matteodelabre mentioned this issue Mar 11, 2021

Implement architecture separation toltec-dev/toltec#310

Merged

bravech mentioned this issue Mar 25, 2021

Client requires server screen size of 260x23936 #22

Closed

matteodelabre closed this as completed Apr 24, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

reMarkable 2 support #15

reMarkable 2 support #15

fedecupe commented Nov 9, 2020

matteodelabre commented Nov 9, 2020

fedecupe commented Nov 9, 2020

LeifAndersen commented Dec 27, 2020

LeifAndersen commented Dec 27, 2020

ennioVisco commented Dec 28, 2020

LeifAndersen commented Dec 28, 2020 •

edited

Loading

Equator11111 commented Dec 30, 2020

LeifAndersen commented Dec 31, 2020

NickHu commented Jan 4, 2021

o- commented Jan 29, 2021

matteodelabre commented Jan 29, 2021 •

edited

Loading

matteodelabre commented Feb 10, 2021 •

edited

Loading

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

kunalb commented Feb 10, 2021

matteodelabre commented Feb 10, 2021

kunalb commented Feb 10, 2021

matteodelabre commented Feb 10, 2021

kunalb commented Feb 10, 2021 •

edited

Loading

matteodelabre commented Feb 10, 2021

fedecupe commented Feb 11, 2021

matteodelabre commented Feb 11, 2021

kunalb commented Feb 11, 2021 •

edited

Loading

matteodelabre commented Feb 11, 2021

kunalb commented Feb 11, 2021

kunalb commented Feb 11, 2021

matteodelabre commented Feb 11, 2021

kunalb commented Feb 11, 2021 •

edited

Loading

Baccanno commented Mar 13, 2021 •

edited

Loading

matteodelabre commented Mar 14, 2021

lapwat commented Apr 14, 2021 •

edited

Loading

matteodelabre commented Apr 24, 2021

reMarkable 2 support #15

reMarkable 2 support #15

Comments

fedecupe commented Nov 9, 2020

matteodelabre commented Nov 9, 2020

fedecupe commented Nov 9, 2020

LeifAndersen commented Dec 27, 2020

LeifAndersen commented Dec 27, 2020

ennioVisco commented Dec 28, 2020

LeifAndersen commented Dec 28, 2020 • edited Loading

Equator11111 commented Dec 30, 2020

LeifAndersen commented Dec 31, 2020

NickHu commented Jan 4, 2021

o- commented Jan 29, 2021

matteodelabre commented Jan 29, 2021 • edited Loading

matteodelabre commented Feb 10, 2021 • edited Loading

This comment has been minimized.

This comment has been minimized.

This comment has been minimized.

kunalb commented Feb 10, 2021

matteodelabre commented Feb 10, 2021

kunalb commented Feb 10, 2021

matteodelabre commented Feb 10, 2021

kunalb commented Feb 10, 2021 • edited Loading

matteodelabre commented Feb 10, 2021

fedecupe commented Feb 11, 2021

matteodelabre commented Feb 11, 2021

kunalb commented Feb 11, 2021 • edited Loading

matteodelabre commented Feb 11, 2021

kunalb commented Feb 11, 2021

kunalb commented Feb 11, 2021

matteodelabre commented Feb 11, 2021

kunalb commented Feb 11, 2021 • edited Loading

Baccanno commented Mar 13, 2021 • edited Loading

matteodelabre commented Mar 14, 2021

lapwat commented Apr 14, 2021 • edited Loading

Workaround instructions

Mono display

Multiple displays landscape mode

matteodelabre commented Apr 24, 2021

LeifAndersen commented Dec 28, 2020 •

edited

Loading

matteodelabre commented Jan 29, 2021 •

edited

Loading

matteodelabre commented Feb 10, 2021 •

edited

Loading

kunalb commented Feb 10, 2021 •

edited

Loading

kunalb commented Feb 11, 2021 •

edited

Loading

kunalb commented Feb 11, 2021 •

edited

Loading

Baccanno commented Mar 13, 2021 •

edited

Loading

lapwat commented Apr 14, 2021 •

edited

Loading