Current Status
| input device | compatible | see oxide#48 |
| battery | compatible | see oxide#48 |
| framebuffer | compatible | rm2fb |
as of 01/01/21, most rM1 apps have been verified as working on the rM2
see rmkit#34 for rmkit’s progress in specific.
Links from around the community
Input Device
The input devices are mostly the same, just linked differently. event0, event1, event2 are no longer mapped in the same order. Now it is recommended to query the ioctl of the devices to detect if they are a touch, stylus or button input.
Alternatively, you can detect if the device is a rM2 and hardcode the correct paths to open.
See oxide#48 for relevant discussion
Battery
The battery lives in a different path in the /sys/ virtual filesystem, see oxide#48 for discussion
FrameBuffer
2020-12-23
rm2fb package has been accepted into toltec repository and should mostly work out of the box
2020-12-07
the last puzzle piece, xochitl, was solved by timower : now the client shim works with xochitl so that xochitl and homebrew apps can co-exist.
2020-11-02
We’ve been experimenting with SWTCON and whether it makes sense to run one SWTCON per process or have a server/client model. So far, signs are pointing towards a server/client model with IPC.
Using the IPC prototype in rm2fb, rmkit apps now work on rM2, (see comments here), including remux and harmony but there is still work to do to make them place nice with xochitl.
2020-10-28
For a demo of drawing to framebuffer see this repo
2020-10-20
Currently, the framebuffer is not well understood. Based on bokluk’s work, there are several observations:
- the display reports as mxsfb/elcdif. it’s unclear whether it uses mxcfb driver or mxsfb driver, it’s also unclear whether it’s using fbdev or DRM/KMS. it seems to be fbdev, though
- the rm1 binary for xochitl contains the string “mxc” when reporting an error with opening fb0, while rm2 binary does not
- /dev/fb0 doesn’t seem to contain information when it’s read from: the sha of the output is the same across devices and scenarios (see reStream#28)
- the only ioctls that seem to be sent to fb0 while drawing on screen is FBIOPAN and FBBLANK
- there is a separate rendering thread that seems to have taken over the work usually being done in hardware
- xochitl loads waveforms off disk and sends them to the display
The goal is to understand how to draw to display which will likely consist of several parts:
- loading the waveform
- writing to memory
- syncing / flushing the memory to the display
Methods used to come to above conclusions
- examining xochitl output
- examining the QA app output
- taking sha and md5sums of buffer
- loading xochitl / QA app in a debugger and stepping through the code
- examining strace output
- using LD_PRELOAD hook to dump ioctl memory values
- using binary analyzers
Artifacts
- https://gist.github.com/raisjnn/97283a7591e933880861238c35ee44e9
- google doc of rM shutdown binary analysis