[9front] Re: [9fans] 9phone

[9front] Re: [9fans] 9phone

[Emil Holmström]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

Sounds interesting, Dave!

I don't know about prior work with 9front on iPhone, but 10 years ago
Inferno was ported to Android:

https://defcon.org/images/defcon-20/dc-20-presentations/Floren/DEFCON-20-Floren-Hellaphone.pdf

/emil

On Mon, Mar 24, 2025 at 6:01 AM Dave MacFarlane via 9fans <9fans@9fans.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-Mdce06ae0664328023dd4b496
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

[-- Attachment #2: Type: text/html, Size: 3622 bytes --]

[9front] Re: [9fans] 9phone

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 3382 bytes --]

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 <9fans@9fans.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-Mdce06ae0664328023dd4b496
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

[-- Attachment #2: Type: text/html, Size: 4348 bytes --]

[9front] Re: [9fans] 9phone

[Dave MacFarlane]

Quoth ron minnich <rminnich@gmail.com>: 
> 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. 
 
Not yet, but the goal is to get there. There's 2 things missing: 
1. There's no audio driver in the kernel yet, which is important to make phone calls (unless you just wanted SMS, but see point 2.) 
2. The modem is connected internally via usb. There's an ehci driver in the kernel which enumerates the endpoints in /dev/usb/ep*, but nusb doesn't have support for the card. One of the endpoints is the serial line for the AT command interface you need to interact with the modem. There's an alternative interface for interacting with the modem over one of the uart ports, but it doesn't seem like it's worth the effort of getting that up and running since another one of the endpoints is the usb audio interface for the other side of the call. I haven't touched this yet (other than the ehci part and verifying the existing drivers won't work) since it's not self-contained in the kernel. 
 
Once those are done, you could technically make phone calls in theory. 
 
* I still need to put them in an fs and put them online somewhere. 
 
- Dave 

[9front] Re: [9fans] 9phone

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

Just my opinion, but in my opinion, if you have sms working, why not get it
upstream so others can join the fun?

Also, some of the cell phone modules I worked with back in the day and an
audio capability on their own. Does the one in the pine phone do that?

On Sat, Mar 29, 2025 at 11:46 AM Dave MacFarlane via 9fans <9fans@9fans.net>
wrote:

> Quoth ron minnich <rminnich@gmail.com>:
> > 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.
>
> Not yet, but the goal is to get there. There's 2 things missing:
> 1. There's no audio driver in the kernel yet, which is important to make
> phone calls (unless you just wanted SMS, but see point 2.)
> 2. The modem is connected internally via usb. There's an ehci driver in
> the kernel which enumerates the endpoints in /dev/usb/ep*, but nusb doesn't
> have support for the card. One of the endpoints is the serial line for the
> AT command interface you need to interact with the modem. There's an
> alternative interface for interacting with the modem over one of the uart
> ports, but it doesn't seem like it's worth the effort of getting that up
> and running since another one of the endpoints is the usb audio interface
> for the other side of the call. I haven't touched this yet (other than the
> ehci part and verifying the existing drivers won't work) since it's not
> self-contained in the kernel.
>
> Once those are done, you could technically make phone calls in theory.
>
> * I still need to put them in an fs and put them online somewhere.
>
> - Dave
>
> ------------------------------------------
> 9fans: 9fans
> Permalink:
> https://9fans.topicbox.com/groups/9fans/T4d13b3016d2a2310-Ma7a79290ec7ca99bcfbd3f9b
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

[-- Attachment #2: Type: text/html, Size: 2575 bytes --]

Re: [9front] Re: [9fans] 9phone

[Dave MacFarlane]

Quoth ron minnich <rminnich@gmail.com>: 
> Just my opinion, but in my opinion, if you have sms working, why not get it 
> upstream so others can join the fun? 
>  
> Also, some of the cell phone modules I worked with back in the day and an 
> audio capability on their own. Does the one in the pine phone do that? 
>  
 
I don't have SMS working..  I just meant SMS doesn't depend on working 
audio output.  SMS needs to go through the AT command interface that 
needs either nusb/serial support for the modem or a better uart driver 
in the kernel that handles more of the uart ports on the soc than just 
uart0 for console output. 
 
I'm not sure if the cell can do audio on its own.  I can't test it for the 
same reason. 
 
- Dave