[9fans] 9phone

[9fans] 9phone

[Dave MacFarlane via 9fans]

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

Re: [9fans] 9phone

[Emil Holmström]

[-- Attachment #1: Type: text/plain, Size: 2492 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-Mb02cfe38dfcd31c4c1090385
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

Re: [9fans] 9phone

[Anthony Sorace]

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

Brian Stuart did a port of Inferno to the Sun SPOT hardware, which has some overlap with the devices in question:

http://iwp9.org/8e/sunspot.pdf

I did an accelerometer on a pi hat a while ago. I think I ended up with the same interface you were describing, but without the normalization, which seems like a good improvement.

I don’t think the Bitsy hardware screen was multi touch, but the software interface certainly wasn’t. From memory, it matches what you describe.

> On Mar 24, 2025, at 03:02, 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-M2a2b3180abf6142a77a54c1f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

Re: [9fans] 9phone

[sirjofri via 9fans]

Hi,

25.03.2025 13:53:02 Anthony Sorace <a@9srv.net>:
> I don’t think the Bitsy hardware screen was multi touch, but the software interface certainly wasn’t. From memory, it matches what you describe.

I'm pretty sure the bitsy wasn't multitouch. I think it was an H3600 series device, and my H3630 certainly wasn't multitouch. I remember using two fingers in solitaire to move cards immediately without dragging and dropping, it was more like synchronized in-sequence tapping of two fingers.

Getting 9front on that device would be great, but also quite useless, especially since the pinephone port is where it is right now. I hope I can find time this year to invent a compatible UI for it.

sirjofri

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4d13b3016d2a2310-Mf93a01185773b777b223ac13
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

Re: [9fans] 9phone

[Brian L. Stuart]

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

Stirring from the ashes of the week from hell...*

On Mon, Mar 24, 2025 at 11:54:59PM -1000, Anthony Sorace wrote:
> Brian Stuart did a port of Inferno to the Sun SPOT hardware, which has some overlap with the devices in question:
> 
> http://iwp9.org/8e/sunspot.pdf

Yes, that would be an example of one way to do it.  In that case,
the devices weren't directly available to the ARM over i2c, but
had an ATMega88 in between that we talk to.

> I did an accelerometer on a pi hat a while ago. I think I ended up with the same interface you were describing, but without the normalization, which seems like a good improvement.

One of the classes I have just wrapped up this term uses the
Pi interfaces to play with various devices.  I'll attach a
Q&D user space program that reads from the i2c MMA8451
accelerometer.  I think if it were me (and we weren't talking
about real-time behavior) I'd leave just the i2c driver in
the kernel and write a user-space server that reads from
it and serves a small tree of device info.

This makes a good time to advertise the upcoming IWP9.  The
paper I'll be giving is related and even touches on the
in-kernel vs user-space question.

* Grades from our Winter term were due today at noon, and this
is probably the farthest behind I've ever been going into the
final push.  Now I have a week and a half to get ready for
the Vintage Computer Festival in NJ, where BTW Brian Kernighan
will be appearing.

BLS


------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4d13b3016d2a2310-M9808b1309f2c605f84ed393d
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

[-- Attachment #2: mma8451sa.c --]
[-- Type: text/x-c, Size: 936 bytes --]

#include <u.h>
#include <libc.h>

void
main()
{
	int fd, cfd, i, n, x, y, z;
	uchar buf[16];

	fd = open("/dev/i2c.1c.data", ORDWR);
	if(fd < 0) {
		bind("#J1c", "/dev", MAFTER);
		fd = open("/dev/i2c.1c.data", ORDWR);
		if(fd < 0)
			print("open error: %r\n");
	}
	cfd = open("/dev/i2c.1c.ctl", ORDWR);
	buf[0] = 0x2a;
	buf[1] = 0x01;
	pwrite(fd, buf, 2, 0);
	fprint(cfd, "subaddress");
	n = pread(fd, buf, 1, 0x0d);
	print("Got ID %d %02x\n", n, buf[0]);
	n = pread(fd, buf, 16, 0x09);
	for(i = 0; i < 16; ++i)
		print("%02x ", buf[i]);
	print("\n");
	pread(fd, buf, 1, 0x2a);
	print("Ctlreg: %02x\n", buf[0]);
	while(1) {
		sleep(1000);
		n = pread(fd, buf, 7, 0x00);
		print("Got %d %02x ", n, buf[0]);
		x = buf[1] << 8 | buf[2];
		if(x & 0x8000)
			x |= ~0x7fff;
		y = buf[3] << 8 | buf[4];
		if(y & 0x8000)
			y |= ~0x7fff;
		z = buf[5] << 8 | buf[6];
		if(z & 0x8000)
			z |= ~0x7fff;
		print("x:%d y:%d z:%d\n", x, y, z);
	}
}

Re: [9fans] 9phone

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 3377 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-Mfd0e401b497dea33b8aa9993
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

Re: [9fans] 9phone

[Dave MacFarlane via 9fans]

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

Re: [9fans] 9phone

[ron minnich]

[-- Attachment #1: Type: text/plain, Size: 1860 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-M9789800ee68c00ea463b049a
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

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

[Dave MacFarlane via 9fans]

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

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4d13b3016d2a2310-M0fe1ac421d0b7da3ea702260
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[adventures in9]

The uart driver in the kernel should only be concerned with uart on
the SoC.  The Allwinner A64 does have more than 1 uart, and the driver
could be expanded to activate them.  But last I looked at the Quectel
EG25 in the Pinephone, it exposed it's own uart as uart over USB.  I
seemed to run everything over USB, including the mobile data, like a
USB ethernet dongle.

On Sat, Mar 29, 2025 at 2:39 PM Dave MacFarlane via 9fans
<9fans@9fans.net> wrote:
>
> 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

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4d13b3016d2a2310-Mafe974a1a142d4a74d98992f
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Dave MacFarlane via 9fans]

Quoth adventures in9 <adventuresin9@gmail.com>:
> The uart driver in the kernel should only be concerned with uart on
> the SoC.  The Allwinner A64 does have more than 1 uart, and the driver
> could be expanded to activate them.  But last I looked at the Quectel
> EG25 in the Pinephone, it exposed it's own uart as uart over USB.  I
> seemed to run everything over USB, including the mobile data, like a
> USB ethernet dongle.

There are 2 interfaces that are exposed by the modem: one over USB
(which is the preferred path, since that's also how it exposes the
gps, and as you said the mobile data), and one on the SOC's UART3.  I
tried to quickly see how easy it would be to add the UART3 port to the
driver tonight since I think ron might be right about the phone's
audio being able to bypass /dev/audio but didn't finish.  I
think the .freq needs to be set to APB2's clock speed and the
i8250baud code needs to be un-#ifdef'd but my laptops battery died
before I figured out the source clock was APB2 so I'm not sure if
that's the only problem.

- Dave

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/T4d13b3016d2a2310-Mad149822bbdeba8e987795b8
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription