Re: [9fans] 9phone

--00000000000083ccff06317cf76f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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=E2=80=AFAM Dave MacFarlane via 9fans <9fans@9f=
ans.net>
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-Mdce06ae0664328=
023dd4b496
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

--00000000000083ccff06317cf76f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">Dave, this is interesting, one thing I&#39;m not sure abou=
t: can you make calls with it? You may have said so, and I missed it.=C2=A0=
<div><br></div><div>I still see the &quot;inferno port&quot; mentioned in t=
hese 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 gett=
ing hosted inferno on OLPC -- we surmised that the Android environment coul=
d support hosted inferno (we actually did a week-long class on &quot;progra=
mming android&quot; to get an idea of what it would take).=C2=A0</div><div>=
<br></div><div>I think a native port is more interesting. If the pinephone =
can function as a phone, I&#39;d sure like to try it. And, if the touchschr=
een is not perfect, well, you have to start somewhere!=C2=A0</div><div><br>=
</div><div>ron</div><div>P.S. The hosted inferno on OLPC was far superior t=
o the &quot;Sugar&quot; Python-based environment that came standard. Infern=
o was far more performant, and used far fewer resources.To Inferno, the amo=
unt 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 t=
his with the OLPC directors, there was no interest.=C2=A0</div></div><br><d=
iv class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gm=
ail_attr">On Mon, Mar 24, 2025 at 6:01=E2=80=AFAM Dave MacFarlane via 9fans=
 &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,2=
04);padding-left:1ex">Hello all,<br>
<br>
I&#39;ve been working on trying to get a pinephone kernel that can run<br>
9front at <a href=3D"https://github.com/driusan/9front-A64" rel=3D"noreferr=
er" target=3D"_blank">https://github.com/driusan/9front-A64</a><br>
<br>
I spent some time this weekend on the userspace getting readings off<br>
the i2c sensors.<br>
<br>
I&#39;ve managed to use /dev/i2c*/ to get data from the:<br>
1. Touch panel<br>
2. Light/proximity sensor<br>
3. Magnetometer<br>
4. Accelerometer/gyroscope<br>
<br>
and now I want to expose the data in a filesystem before I put it<br>
online in some other repo.=C2=A0 I&#39;ve done some looking around but can&=
#39;t<br>
find any prior art for any of the above sensor types in Plan9.=C2=A0 Does<b=
r>
anyone know of any?=C2=A0 I&#39;d like to aim for compatibility if they exi=
st.<br>
<br>
Assuming they don&#39;t, I&#39;m looking for input if anyone has any strong=
<br>
opinions on what the interface should look like.<br>
<br>
Left to my own devices my plan is:<br>
<br>
1. TouchPanel -- just write to /dev/mousein and treat touches as<br>
=C2=A0 =C2=A0button 1.=C2=A0 Since it&#39;s a userspace driver we can exper=
iment with<br>
=C2=A0 =C2=A0multitouch later.<br>
2. Light/proximity sensor - create a /dev/lightsensor that<br>
=C2=A0 =C2=A0returns light readings.=C2=A0 A /dev/proximity read returns &q=
uot;close&quot; or<br>
=C2=A0 =C2=A0&quot;notclose&quot;.=C2=A0 No ctl files or scaling.<br>
3. Magnetometer - /dev/compass blocks until there&#39;s enough<br>
=C2=A0 =C2=A0data to calibrate.=C2=A0 Reads return 3 values, x y z that are=
 the raw<br>
=C2=A0 =C2=A0(short int) readings.=C2=A0 /dev/compassctl for calibrating<br=
>
=C2=A0 =C2=A0sensitivity/etc.<br>
4. Accel/gyroscope - /dev/accel returns 6 readings of the<br>
=C2=A0 =C2=A0raw (also short) value ax ay az gx gy gz.=C2=A0 /dev/accelctl<=
br>
=C2=A0 =C2=A0for customizing sensitivity/etc.<br>
<br>
x/y/z aren&#39;t the raw sensor orientation, but normalized so that +y is t=
he<br>
top of the screen, +x is to the right, and +z is towards the back of the<br=
>
phone.<br>
<br>
I&#39;ve done the work to read the values but haven&#39;t done any work to<=
br>
expose it other than printing debugging to stdout, so I&#39;m open to<br>
suggestions to other interfaces.<br>
<br>
- Dave<br>
<br>
------------------------------------------<br>
9fans: 9fans<br>
Permalink: <a href=3D"https://9fans.topicbox.com/groups/9fans/T4d13b3016d2a=
2310-Mdce06ae0664328023dd4b496" rel=3D"noreferrer" target=3D"_blank">https:=
//9fans.topicbox.com/groups/9fans/T4d13b3016d2a2310-Mdce06ae0664328023dd4b4=
96</a><br>
Delivery options: <a href=3D"https://9fans.topicbox.com/groups/9fans/subscr=
iption" rel=3D"noreferrer" target=3D"_blank">https://9fans.topicbox.com/gro=
ups/9fans/subscription</a><br>
</blockquote></div>

--00000000000083ccff06317cf76f--