reMarkable 2 support

[torwag]

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]

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]

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]

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]

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]

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

[ddvk]

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

[ddvk]

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]

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

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

[raisjn]

/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]

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]

@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]

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

[Eeems]

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

[Eeems]

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

[LinusCDE]

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]

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]

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

[tocklime]

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

[Eeems]

@ddvk Have you found the pogo port in sysfs?

[ddvk]

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

[jonahweissman]

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]

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?

[jonahweissman]

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

reMarkable 2.0

That one works!

Also, I was grepping around for other places a version number might be, and I found these two spots:

• /sys/firmware/devicetree/base/model. This seems to be the same as /sys/devices/soc0/machine but without a newline. It contains reMarkable 1.0 on my reMarkable 1.
• /usr/share/remarkable/update.conf. If this is where the params for the update engine are stored, then this would be very reliable, but the #PLATFORM=reMarkable2 line starts with a # so it might not be actively used. The line is #PLATFORM=reMarkable on my reMarkable 1.

edit: It looks like the update engine consults /sys/devices/soc0/machine to get the platform version, so that is probably the most canonical source.

https://github.com/reMarkable/update_engine/blob/bcb3bf5e667c6b346d0aa65b1c1c215b108a6d42/src/update_engine/utils.cc#L67 https://github.com/reMarkable/update_engine/blob/b1ff31229be589ba0916eaa7cbd4e387679e0ed3/src/update_engine/omaha_request_params.cc#L45

[Eeems]

Interesting, so they just check for reMarkable 2.0 and don't validate any other versions.

[raisjn]

If anyone is wondering, the touchscreen is setup differently (in terms of coordinates) than the rM1 touchscreen. In specific, the touchscreen previously required scaling the touch because the touch display reported a different resolution (767x1023) but now the touch screen seems to have the correct resolution. Additionally, the X coordinate no longer needs inversion (WIDTH - X), but the Y coordinate still requires inversion (HEIGHT - Y).

The stylus works as previously, though, afaict.

[Eeems]

Currently blocked by https://github.com/ddvk/remarkable2-framebuffer/issues/30 and the lack of alternative methods to trigger long press actions.

[Eeems]

So all that's really remaining is alternative methods to trigger long press actions.

[LinusCDE]

Could it work to have something akin to notifications pop up when long pressing power to present all the options?

[ddvk]

how about long swipe bottom to top

[Eeems]

I'm thinking that a new application will need to be written to implement this instead of building it into the system service. That way users could change it to how they want.

[Jcwscience]

I’m using the rm2fb from Toltec. Aside from the other issues mentioned in this thread, any touch input aside from the stylus seems to take approximately 0.75 seconds to register. Menu items only work with the stylus, and main actions such as app launch and FingerTerm only work with touch.

[Eeems]

Anybody else experiencing the slow response on touch or pen input? As for menu items only working with a stylus, which applications exhibit this? Fingerterm only supports touch input on any device. Launching an application from oxide only works with touch due to how I had to implement pen input in the Qt framework.

[Jcwscience]

My mistake. The menu does work with touch although it exhibits the same problem. I have to tap multiple times, or sometimes holding for 3/4 of a second or so will trigger the item. Seems to be with all touch input. I didn’t notice koreader because it only works with stylus input right now

[Eeems]

I didn’t notice koreader because it only works with stylus input right now

Are you using the latest nightly build? Or just what is in toltec?

The same install of fingerterm launched from draft doesn’t have this issue, so I am assuming it has something to do with how the application is called. Or if input is forwarded through oxide to the application layer below that might be the cause. I’ve been trying to isolate the problem to a specific step in the program, but I’m not that experienced with the ReMarkable Linux system yet.

Oxide only has custom handling for button input, which isn't used on the rM2 for anything other than the power button. Could you maybe check to see what CPU usage is like when using input? @Witos are you also noticing this slowdown?

[Jcwscience]

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]

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]

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

[Evidlo]

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]

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

[LinusCDE]

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]

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]

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

[Witos]

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]

@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]

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]

@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]

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

[danshick]

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]

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]

oxide 2.1~beta1 fixed the issue