reMarkable 2 support #48

torwag · 2020-09-10T16:07:45Z

The rM2 has different device pathes and hence it requires some adaption to run oxide on the rM2.

A file-tree of the sys folder rM2 was provided by @ddvk is here:
tree.txt

Eeems · 2020-09-11T01:05:12Z

I'll solve this by making my code able to handle any number of battery and charger devices :P

It looks like wlan0 is the same, so I wont touch that.

Eeems · 2020-09-11T02:10:38Z

Battery/Charger should be fixed by fb1ac1c

By the looks of it the input devices on the rM2 are:

event0: power button
event1: wacom
event2: touchscreen

Which does not match the rM1:

event0: wacom
event1: touchscreen
event2: buttons

Without having an rM2 to play around with I'm not sure how to make my code dynamically figure out which input to use for which.

@ddvk Would you mind checking my battery code on the rM2? My charger code may not detect properly if it isn't reporting as a type of "USB".

ddvk · 2020-09-11T11:38:45Z

oxide is throwing:
Couldn't find the file /sys/class/power_supply/max77818_battery/capacity_level
terminate called after throwing an instance of 'std::logic_error'
what(): basic_string::_M_construct null not valid
Initializing...
Creating new WifiManager instance on /fi/w1/wpa_supplicant1/Interfaces/1
Loading networks...

erode:
Framebuffer has wrong id: "mxs-lcdif"
QFSFileEngine::map: Mapping a file beyond its size is not portable

Eeems · 2020-09-11T18:40:47Z

So we need a different static library for the framebuffer, that will be unsolvable until that's provided. As for the battery, I guess I didn't look too closely at the filetree output. It doesn't have capacity_level, which upon closer look I can calculate for myself with capacity. I'll update my code to remove its usage and make it a bit smarter about detecting what it can use.

@ddvk What does status_ex output? I'm not seeing it in the kernel documentation (https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-power)

Eeems · 2020-09-13T05:51:11Z

https://gist.github.com/raisjn/01b16286dcc4461a6643f40f8f553966

ddvk · 2020-09-13T19:34:15Z

/dev/input/event0 2 3
/dev/input/event1 1 1
/dev/input/event2 0 0
/dev/input/mice 4 3

ddvk · 2020-09-13T19:35:23Z

So we need a different static library for the framebuffer, that will be unsolvable until that's provided. As for the battery, I guess I didn't look too closely at the filetree output. It doesn't have capacity_level, which upon closer look I can calculate for myself with capacity. I'll update my code to remove its usage and make it a bit smarter about detecting what it can use.

@ddvk What does status_ex output? I'm not seeing it in the kernel documentation (https://www.kernel.org/doc/Documentation/ABI/testing/sysfs-class-power)

cat /sys/class/power_supply/max77818_battery/status_ex
USB-C connected

Eeems · 2020-09-13T19:46:50Z

cat /sys/class/power_supply/max77818_battery/status_ex
USB-C connected

That's interesting. I wonder what the other possible values are.

raisjn · 2020-09-13T19:50:50Z

/dev/input/event0 2 3
/dev/input/event1 1 1
/dev/input/event2 0 0
/dev/input/mice 4 3

looks good, id_by_capabilities() is working (and is recommended way to identify the device types, imo). event0 must have different name than 'gpio-keys' (and why it is returning UNKNOWN by_name).

these values line up with the stated ones, as well: event0 = button, event1 = stylus, event2 = touch

LinusCDE · 2020-09-24T04:25:13Z

Seems that here is some interesting info about the changes of the rM2. Would be really great, if we could that add to some wiki somewhere.

For the version check /home/root/.config/remarkable/xochitl.conf for the value of deviceid. That contains the serial number which should start with RM200- if I'm not mistaken.

I also stumbled on /sys/devices/soc0/machine which gives me reMarkable 1.0 back. I guess the rM2 would reMarkable 2.0. Can you back this up @ddvk ? This might be easier for other programs to read out.

I also saw that we might be able to find at least some common paths to the evdevs. Are these also present and the same on the rM2?

GPIO: /dev/input/by-path/platform-gpio-keys-event
Wacom: /dev/input/by-path/platform-21a4000.i2c-event-mouse and /dev/input/touchscreen0
Multitouch /dev/input/by-path/platform-21a8000.i2c-event

I doubt that the ones with hardware addresses will work here. But we may be able to use the other ones to have a single path for GPIO and Wacom.

My guess would be that on the rM2 these paths would be used for the ones with plaformspecific paths:

Wacom: /dev/input/by-path/platform-30a20000.i2c-event-mouse
Multitouch: /dev/input/by-path/platform-30a40000.i2c-event

raisjn · 2020-09-24T04:49:55Z

@LinusCDE the code from above that identifies a device FD based on capabilities is enough because the devices exist at /dev/input/event{0,1,2} on rm1 and rm2 and can be queried; they are just symlinked differently

ddvk · 2020-09-24T09:16:26Z

reMarkable: ~/ cat /sys/devices/soc0/machine
reMarkable 2.0

Eeems · 2020-09-24T14:10:46Z

I think that would be the preferred way to detect which device you are on.

Eeems · 2020-09-24T15:21:41Z

I decided to run it on mine... Umm...

LinusCDE · 2020-09-26T23:26:36Z

So valid way seem to be:

Reading xochitls config and checking for RM1 or RM2 (not RM100 as at least the last digit has variations for the RM1 like RM102)
Reading sys/devices/soc0/machine but checking for preferably a 1.0 or a 2.0. If none is present check for 1 or 2 (not the other way as a potential 2.1 might confuse that)
Do a readlink on /dev/input/touchscreen0 (points to the wacom digitizer) and check whether it contains either event0 (rM1) or event1 (rM2). This assumes that this file exists on the rM2, but I'm fairly optimistic about that.

tocklime · 2020-10-15T06:57:17Z

cat /sys/class/power_supply/max77818_battery/status_ex
USB-C connected

That's interesting. I wonder what the other possible values are.

From my RM2:

reMarkable: ~/ cat /sys/class/power_supply/max77818_battery/status
Discharging
reMarkable: ~/ cat /sys/class/power_supply/max77818_battery/status
Charging
reMarkable: ~/ cat /sys/class/power_supply/max77818_battery/status_ex
USB-C connected
reMarkable: ~/ cat /sys/class/power_supply/max77818_battery/status_ex
Charger not connected

I tried with a usb c cable connected to PC and one connected to a power adapter, but both just say 'Charging'/'USB-C connected'

Eeems · 2020-10-15T14:10:39Z

Interesting, so it's providing duplicate functionality to the charger's sysfs status.

tocklime · 2020-10-15T15:58:03Z

Oh, I wonder if it does anything about the usb pogo port. I don't have a connector for that.

Eeems · 2020-10-15T16:00:08Z

@ddvk Have you found the pogo port in sysfs?

ddvk · 2020-10-15T17:15:32Z

there is /sys/otgcontrol that controls the pogo ports mode (host, gadget), also it is just usb

jonahweissman · 2020-10-26T00:22:29Z

So valid way seem to be:

Reading xochitls config and checking for RM1 or RM2 (not RM100 as at least the last digit has variations for the RM1 like RM102)

My reMarkable 2 has a deviceid that starts with RM110, so it might be more complicated than just checking the first digit.

Eeems · 2020-10-26T03:18:25Z

So valid way seem to be:

Reading xochitls config and checking for RM1 or RM2 (not RM100 as at least the last digit has variations for the RM1 like RM102)

My reMarkable 2 has a deviceid that starts with RM110, so it might be more complicated than just checking the first digit.

Darn :( What does cat /sys/devices/soc0/machine return for you?

Jcwscience · 2020-12-23T22:46:06Z

Edit: I believe I am possibly experiencing a side effect of the buffered input bug. And i am using the Toltec version, I will try installing the latest build and letting you know. It doesn’t seem like an issue with the program itself, even Xochitl shows the same touch issues when launched. It also seems that the Application launcher is not filtering the input, ie, if I touch a button in the upper left-hand side of Xochitl, The corresponding app which in my case the process manager will immediately launch on exiting back to oxide.

Jcwscience · 2020-12-23T23:01:19Z

Last edit: I have traced the problem to my rm2fb install. Sorry to bother you with troubleshooting. If there is anything you would like me to test on my device in the future let me know.

Eeems · 2020-12-23T23:04:17Z

@Jcwscience No worries :) Glad to help troubleshoot, even if it's not my code that's at fault.

@torwag

This was not tested. Though by viewing the file tree of /sys provided by @torwag (Eeems-Org/oxide#48 (comment) file tree.txt line 3166) it seems that all methods are supported.

@torwag

This was not tested. Though by viewing the file tree of /sys provided by @torwag (Eeems-Org/oxide#48 (comment) file tree.txt line 3166) it seems that all methods are supported.

Evidlo · 2020-12-26T17:32:45Z

On my rM1 from 2018:

[root@remarkable ~] cat /sys/devices/soc0/machine 
reMarkable Prototype 1

[root@remarkable ~] cat /usr/share/remarkable/update.conf 
[General]
REMARKABLE_RELEASE_APPID={98DA7DF2-4E3E-4744-9DE6-EC931886ABAB}
REMARKABLE_RELEASE_VERSION=2.1.1.3
GROUP=Prod
ID=
SERVER=https://get-updates.cloud.remarkable.engineering/service/update2

[root@remarkable ~] cat /sys/firmware/devicetree/base/model 
reMarkable Prototype 1[root@remarkable ~]

Eeems · 2020-12-26T17:54:30Z

I think it's getting safer to say that the possible rM1 values are reMarkable 1 and reMarkable Prototype 1

LinusCDE · 2020-12-26T18:00:00Z

I think it's getting safer to say that the possible rM1 values are reMarkable 1 and reMarkable Prototype 1

Agreed. If anybody finds new values, an issue on libremarkable would be welcome to add that to this internal list as well: https://github.com/canselcik/libremarkable/blob/075c05081c26f0fa47ac609b0d18c90082617f5c/src/device.rs#L25

danshick · 2021-01-07T15:04:08Z

Last edit: I have traced the problem to my rm2fb install. Sorry to bother you with troubleshooting. If there is anything you would like me to test on my device in the future let me know.

I have the same kind of missed inputs/input lag issue with tarnish enabled. For me, it doesn't seem to be rm2fb because other apps work fine (fingerterm launched with remux with tarnish disabled works fine, but fingerterm launched by oxide is nearly impossible to type on).

CPU usage stays below 20% with oxide/tarnish running, so I don't think that's the issue.

The input trouble follows me to xochitl launched by oxide too. I have to click anywhere from one to five times on a menu or control to get it to activate, and there's significant lag between a press and the action. Same goes for fingerterm and even oxide/erode itself.

Eeems · 2021-01-07T15:07:36Z

Very odd. @Witos do you experience this as well?

Witos · 2021-01-07T16:05:37Z

Yes, it happened to me with the other launcher (remux),but never with oxide that's why I use it. Xochitl / Koreader launched with remix had such a big lag that they were barely usable.

Jcwscience · 2021-01-07T16:10:03Z

@danshick I couldn't ever get the source build of rm2fb to work properly. I'm using the Toltec version, and the oxide v2.1 source build. Seems to have fixed most problems although I am still having an issue where suspending with the tarnish power menu causes the screen to stay white until reboot.

Witos · 2021-01-07T16:14:06Z

Everything works for me in terms of Oxide / Tarnish / KOreader / Xochitl apart from issue #135, which is not a deal breaker. I'm using 2.1 oxide and rm2fb head.

Eeems · 2021-01-07T16:57:13Z

@danshick I couldn't ever get the source build of rm2fb to work properly. I'm using the Toltec version, and the oxide v2.1 source build. Seems to have fixed most problems although I am still having an issue where suspending with the tarnish power menu causes the screen to stay white until reboot.

Hmm, v2.1 shouldn't have an issue with suspend anymore. Do you have any reproduction steps that are consistent? Could it be related to #135?

Jcwscience · 2021-01-07T16:59:11Z

That sounds like it, I'll see if I can work out the exact circumstances this afternoon and let you know.

danshick · 2021-01-07T18:57:17Z

I was trying both oxide/tarnish and rm2fb from toltec testing as of yesterday. And nothibg was needed to trigger. As soon as xochitl was disabled and tarnish was enabled (both with --now), everything lagged hard. As soon as I disabled tarnish and reenabled xochitl, I was back to full speed. Enabling remux (also from testing) didn't cause a slowdown.

I guess I should try building HEAD for both repos. I wish we had AUR style VCS repos, but there's probably no chance of building on-device reasonably fast.

Eeems · 2021-01-07T19:19:17Z

toltec packages are inspired by the archlinux PKBUILD format, so you could in theory build locally and copy over the ipk. Most of our builds are just pulling precompiled binaries though which makes it less usable for what you are wanting.

I wonder if rm2fb is the issue here? Maybe on your device the communication with the screen is lagging due to ipc communication slowdowns of some sort?
@raisjn @ddvk

danshick · 2021-01-07T21:09:19Z

oxide 2.1~beta1 fixed the issue

jdkruzr · 2021-01-20T23:32:45Z

hey there -- I installed Oxide from zip and installed rm2fb from Toltec. once launching Xochitl, how does one return to Oxide? thanks!

LinusCDE · 2021-01-21T00:54:36Z

hey there -- I installed Oxide from zip and installed rm2fb from Toltec. once launching Xochitl, how does one return to Oxide? thanks!

Hi. Currently the best option seems to use genie. Genie is a systemd-service in the background that can run commands on certain gestures. Here is a good sample config for oxide (paste it to /opt/etc/genie.conf). (Not sure if it's still the case but when suspending/waking up the guestures can mis-trigger.)

Eeems · 2021-01-21T12:28:31Z

I feel like nobody reads the release notes :(

LinusCDE · 2021-01-21T15:24:33Z

I feel the same. Everything relaying current information should probably just go into the readme as people will look there. I personally keep to only stating changes and sometimes hint or repeat what I put in the readme.

afogel · 2021-01-28T14:18:44Z

FWIW, I read release notes and README, but I'm still having difficulty figuring out how to get oxide to import and launch KOreader. Maybe it's the draft config that I'm not setting up correctly -- I tried to remove the call= line as well as the term= line, but that also didn't help.

name=koreader
desc=EBook reader
call=/home/root/koreader/koreader.sh
term=:

Regardless, @Eeems, I appreciate the work! N.B. there's a small typo in the Usage section: "Oxide consists of siz applications", I think it should be six applications.

Eeems · 2021-01-28T14:20:50Z

Have you tried installing KOReader from toltec? It will automatically register the application for you using an oxide application registration file instead of draft.

Thanks for letting me know about the typo, I'll go fix it.

afogel · 2021-01-28T14:30:13Z

Got it, thanks!

Eeems · 2022-01-08T05:35:47Z

It's probably safe to say that this can be closed.

Eeems added the enhancement New feature or request label Sep 11, 2020

Eeems added the help wanted Extra attention is needed label Sep 23, 2020

Eeems changed the title ~~new pathes needed for rM2~~ reMarkable 2 support Sep 23, 2020

Eeems mentioned this issue Sep 29, 2020

Screensaver not loading on reMarkable: Requires extra button press koreader/koreader#6676

Closed

gbyl mentioned this issue Oct 14, 2020

Support for Remarkable 2 koreader/koreader#6792

Closed

This was referenced Oct 16, 2020

Does not work on reMarkable 2 rien/reStream#28

Closed

Doesn't render UI on reMarkable v2 dixonary/draft-reMarkable#25

Open

Evidlo mentioned this issue Oct 25, 2020

[remarkable2 support]: change event files based on rM version Evidlo/remarkable_mouse#32

Closed

LinusCDE mentioned this issue Dec 24, 2020

Add support for the rM2 battery canselcik/libremarkable#51

Merged

LinusCDE mentioned this issue Jan 1, 2021

Detect more rM 1 devices with debatable changes rien/reStream#36

Closed

NickHu mentioned this issue Jan 4, 2021

reMarkable 2 support matteodelabre/vnsee#15

Closed

Eeems closed this as completed Jan 8, 2022

reMarkable 2 support #48

reMarkable 2 support #48

Comments

torwag commented Sep 10, 2020

Eeems commented Sep 11, 2020

Eeems commented Sep 11, 2020 • edited

ddvk commented Sep 11, 2020

Eeems commented Sep 11, 2020

Eeems commented Sep 13, 2020 • edited

ddvk commented Sep 13, 2020

ddvk commented Sep 13, 2020

Eeems commented Sep 13, 2020

raisjn commented Sep 13, 2020 • edited

LinusCDE commented Sep 24, 2020

raisjn commented Sep 24, 2020

ddvk commented Sep 24, 2020

Eeems commented Sep 24, 2020

Eeems commented Sep 24, 2020

LinusCDE commented Sep 26, 2020 • edited

tocklime commented Oct 15, 2020

Eeems commented Oct 15, 2020

tocklime commented Oct 15, 2020

Eeems commented Oct 15, 2020

ddvk commented Oct 15, 2020

jonahweissman commented Oct 26, 2020

Eeems commented Oct 26, 2020

Jcwscience commented Dec 23, 2020 • edited

Jcwscience commented Dec 23, 2020

Eeems commented Dec 23, 2020

Evidlo commented Dec 26, 2020 • edited

Eeems commented Dec 26, 2020

LinusCDE commented Dec 26, 2020

danshick commented Jan 7, 2021

Eeems commented Jan 7, 2021

Witos commented Jan 7, 2021 • edited

Jcwscience commented Jan 7, 2021

Witos commented Jan 7, 2021 • edited

Eeems commented Jan 7, 2021

Jcwscience commented Jan 7, 2021

danshick commented Jan 7, 2021 • edited

Eeems commented Jan 7, 2021

danshick commented Jan 7, 2021

jdkruzr commented Jan 20, 2021

LinusCDE commented Jan 21, 2021

Eeems commented Jan 21, 2021

LinusCDE commented Jan 21, 2021

afogel commented Jan 28, 2021 • edited

Eeems commented Jan 28, 2021

afogel commented Jan 28, 2021

Eeems commented Jan 8, 2022

Eeems commented Sep 11, 2020 •

edited

Eeems commented Sep 13, 2020 •

edited

raisjn commented Sep 13, 2020 •

edited

LinusCDE commented Sep 26, 2020 •

edited

Jcwscience commented Dec 23, 2020 •

edited

Evidlo commented Dec 26, 2020 •

edited

Witos commented Jan 7, 2021 •

edited

Witos commented Jan 7, 2021 •

edited

danshick commented Jan 7, 2021 •

edited

afogel commented Jan 28, 2021 •

edited