View Single Post
Old 08-10-2022, 06:41 AM   #450
pazos
cosiņeiro
pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.pazos ought to be getting tired of karma fortunes by now.
 
Posts: 1,406
Karma: 2451781
Join Date: Apr 2014
Device: BQ Cervantes 4
Hi.

I did a quick research to give a better answer than my previous one. Hopefully is useful if anybody plans to add support for pocketbook gsensor.

1. Based on this comment /dev/input is populated but not readable by non-root users. So handling it that way is a big nope

2. Pocketbook SDK already includes ways to deal with gsensor. You can grep https://github.com/koreader/koreader.../inkview_h.lua with "gsensor". Optionally with "orientation", I dunno if they're the same.

There're two functions that look apealing:

Code:
int QueryGSensor();
Code:
int ReadGSensor(int *, int *, int *);
Since Pocketbook API is mostly undocumented the best way to understand what it does is trying to understand the output on the real thing.

I'm assuming QueryGSensor returns a kind of orientation that can be enumerated (but there's no enum as part of the api) while ReadGSensor is more like a boolean function where you pass a pointer to each one of the 3-axis, and if the function returns ok you can trust these three pointers contain valid data for a given moment of time. Normally 3-axis acelerometers return a value on range 0-255 (or -127 - 127), but there's no way to know that beforehand.

3. While the pocketbook api is already accesible using LuaJIT's ffi in this case we might want to keep the implementation in C, as part of https://github.com/koreader/koreader...t-pocketbook.h

The reason is: unlike other calls that are driven by the user, like set the frontlight level, this one needs to be run in an event loop. We're going to expect an event each time the gsensor changes. In that regard we're just polling there to keep the common base/frontend code cleaner and "event-driven".

4. You need to figure out how to deal with corner cases.

Two types:

4.1 deal with devices that have no gsensor.
4.2 deal with legacy devices that ship an inkview library that has missing symbols for the functions you're using.


You can probably skip both in the research stage and just figure out a way that works on your device. Then push a patch and gather some feedback (does it work the same on other gsensor devices?, does it crash if the device lacks a gsensor?, does work on FW4.X?).

TL;DR: Use Pocketbook API and document what different functions are doing when called.
pazos is offline   Reply With Quote