Dave, this is interesting, one thing I'm not sure about: can you make calls with it? You may have said so, and I missed it.
I still see the "inferno port" mentioned in these discussions. If you mean the work we did at Sandia long ago, that was hosted inferno. The inspiration for that work was our early experience getting hosted inferno on OLPC -- we surmised that the Android environment could support hosted inferno (we actually did a week-long class on "programming android" to get an idea of what it would take). I think a native port is more interesting. If the pinephone can function as a phone, I'd sure like to try it. And, if the touchschreen is not perfect, well, you have to start somewhere! ron P.S. The hosted inferno on OLPC was far superior to the "Sugar" Python-based environment that came standard. Inferno was far more performant, and used far fewer resources.To Inferno, the amount of RAM felt like infinity; to Sugar, it was never enough. Everything we did in Sugar was S*L*O*W; inferno was really peppy. But when I discussed this with the OLPC directors, there was no interest. On Mon, Mar 24, 2025 at 6:01 AM Dave MacFarlane via 9fans <[email protected]> wrote: > Hello all, > > I've been working on trying to get a pinephone kernel that can run > 9front at https://github.com/driusan/9front-A64 > > I spent some time this weekend on the userspace getting readings off > the i2c sensors. > > I've managed to use /dev/i2c*/ to get data from the: > 1. Touch panel > 2. Light/proximity sensor > 3. Magnetometer > 4. Accelerometer/gyroscope > > and now I want to expose the data in a filesystem before I put it > online in some other repo. I've done some looking around but can't > find any prior art for any of the above sensor types in Plan9. Does > anyone know of any? I'd like to aim for compatibility if they exist. > > Assuming they don't, I'm looking for input if anyone has any strong > opinions on what the interface should look like. > > Left to my own devices my plan is: > > 1. TouchPanel -- just write to /dev/mousein and treat touches as > button 1. Since it's a userspace driver we can experiment with > multitouch later. > 2. Light/proximity sensor - create a /dev/lightsensor that > returns light readings. A /dev/proximity read returns "close" or > "notclose". No ctl files or scaling. > 3. Magnetometer - /dev/compass blocks until there's enough > data to calibrate. Reads return 3 values, x y z that are the raw > (short int) readings. /dev/compassctl for calibrating > sensitivity/etc. > 4. Accel/gyroscope - /dev/accel returns 6 readings of the > raw (also short) value ax ay az gx gy gz. /dev/accelctl > for customizing sensitivity/etc. > > x/y/z aren't the raw sensor orientation, but normalized so that +y is the > top of the screen, +x is to the right, and +z is towards the back of the > phone. > > I've done the work to read the values but haven't done any work to > expose it other than printing debugging to stdout, so I'm open to > suggestions to other interfaces. > > - Dave ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/T4d13b3016d2a2310-Mfd0e401b497dea33b8aa9993 Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
