Client does not work with remarkable.net

[i-am-shodan]

When using Remarkable.net error messages can be seen in stdout and the display doesn’t update. The error messages can be tracked back to display refresh code in remarkable.net and specifically the C# ioctl call into libc returning -1.

I debugged this at great length with a debug build of the r2fb client and enabled function level debug logging going to stdout.

The client library was preloaded correctly into dotnet and the function tracer output could be seen. However when the main application (my DLL instead of the dotnet interpreter binary) was running it appeared that the function hooks were not being called at all.

I suspect that the existing open/close/ioctl hooks don’t work at all with dotnet applications.

As a workaround I preloaded the binary but also invoked functions directly in the client library instead of libc. At which point everything worked as expected.

I will put a PR into remarkable.net to call the client libraries directly but long term it might be better to have an API (socket, tcp) to use instead as when the client version number changes remarkable.net will break.

[Eeems]

@i-am-shodan parzivail/ReMarkable.NET#5 this was the PR you mentioned, right?

As for the API, it's not really documented well, but the client does have a protocol that it uses to communicate with the server that can be used. It's using msgsnd to send messages to a message queue that the server handles. It also uses smem_open to allow waiting on updates to complete.

remarkable2-framebuffer/src/client/main.cpp

Lines 132 to 191 in 833dcbd

	if (request == MXCFB_SEND_UPDATE) {
	mxcfb_update_data *update = (mxcfb_update_data *)ptr;
	MSGQ.send(*update);
	return 0;
	} else if (request == MXCFB_SET_AUTO_UPDATE_MODE) {
	return 0;
	} else if (request == MXCFB_WAIT_FOR_UPDATE_COMPLETE) {
	#ifdef DEBUG
	std::cerr << "CLIENT: sync" << std::endl;
	#endif
	if (!DO_WAIT_IOCTL) {
	return 0;
	}
	// for wait ioctl, we drop a WAIT_t message into the queue. the server
	// then uses that message to signal the semaphore we just opened. this
	// can take as little as 0.5ms for small updates. one difference is that
	// the ioctl now waits for all pending updates, not just the requested
	// scheduled one.
	swtfb::ClockWatch cz;
	swtfb::wait_sem_data update;
	std::string sem_name = std::string("/rm2fb.wait.");
	sem_name += std::to_string(getpid());
	memcpy(update.sem_name, sem_name.c_str(), sem_name.size());
	update.sem_name[sem_name.size()] = 0;
	MSGQ.send(update);
	sem_t *sem = sem_open(update.sem_name, O_CREAT, 0644, 0);
	struct timespec timeout;
	if (clock_gettime(CLOCK_REALTIME, &timeout) == -1) {
	// Probably unnecessary fallback
	timeout = {0, 0};
	#ifdef DEBUG
	std::cerr << "clock_gettime failed" << std::endl;
	#endif
	}
	timeout.tv_nsec += SEM_WAIT_TIMEOUT;
	// Move overflow ns to secs
	timeout.tv_sec += timeout.tv_nsec / (long) 1e9;
	timeout.tv_nsec %= (long) 1e9;
	sem_timedwait(sem, &timeout);
	// on linux, unlink will delete the semaphore once all processes using
	// it are closed. the idea here is that the client removes the semaphore
	// as soon as possible
	// TODO: validate this assumption
	sem_unlink(update.sem_name);
	#ifdef DEBUG
	std::cerr << "FINISHED WAIT IOCTL " << cz.elapsed() << std::endl;
	#endif
	return 0;
	}

[i-am-shodan]

Yeah that would be it

[Eeems]

#14 was where progress was previously tracked for getting rm2fb to work with all the frameworks/libraries. It might be safe to close both that issue and this issue. We'll just revisit it when we need to make breaking changes to rm2fb, or if someone wants to change the remarkable.net implementation to directly speak the protocol.