[9front] 9phone

[9front] 9phone

[Dave MacFarlane]

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 

Re: [9front] 9phone

[Dan Cross]

On Mon, Mar 24, 2025 at 8:36 AM Dave MacFarlane <driusan@driusan.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.

The Bitsy kernel (for the Compaq iPaq) supported the touch screen on
that device.  I don't recall that it worked very well, but it did
work.  You may look at using that as a starting point for the touch
panel part.

> 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.

It might be odd to block until calibrated. Perhaps consider returning
special sentinel values in this case.

> 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.

For many of the sensors you may be in more or less uncharted
territory; the touch screen may look something like the Bitsy.  My
sense is that as long as you emit some reasonable data from those
devices you're ok, as presumably most of the interesting processing
would happen in userspace.  If it were me, I'd start prototyping with
what you have above, and then fine tune your data formats as you get a
sense for what you really need.

        - Dan C.

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

[Dave MacFarlane]

Quoth Dan Cross <crossd@gmail.com>: 
> The Bitsy kernel (for the Compaq iPaq) supported the touch screen on 
> that device.  I don't recall that it worked very well, but it did 
> work.  You may look at using that as a starting point for the touch 
> panel part. 
> 
 
The touchscreen is the easiest part, since mousein can already take 
absolute coordinates.  I've already written that part and use the 
volume keys as button 2&3.  It works okay. 
 
I've been using bitsy/keyboard -n with the touch screen and it works 
fine for bootstrapping but not well by modern standards.  It's easy to 
fat-finger things because there's too many keys on screen and swipe 
input would be nice.  It also won't disable itself when the proximity 
sensor detects something close once that's exposed. 
 
>  
> For many of the sensors you may be in more or less uncharted 
> territory; the touch screen may look something like the Bitsy.  My 
> sense is that as long as you emit some reasonable data from those 
> devices you're ok, as presumably most of the interesting processing 
> would happen in userspace.  If it were me, I'd start prototyping with 
> what you have above, and then fine tune your data formats as you get a 
> sense for what you really need. 
>  
>         - Dan C. 
 
The "most of the interesting processing would happen in userspace" bit 
is why I'm considering returning the raw sensor values rather than 
doing the work of converting to metric/real world values from the 
driver but I could be convinced that's a bad idea. 
 
- Dave 

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

[ron minnich]

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

I like your raw data from kernel idea, putting interesting processing in
user spaces makes bug fixes ever so much easier :-)

On Mon, Mar 24, 2025 at 7:09 AM Dave MacFarlane via 9fans <9fans@9fans.net>
wrote:

> Quoth Dan Cross <crossd@gmail.com>:
> > The Bitsy kernel (for the Compaq iPaq) supported the touch screen on
> > that device.  I don't recall that it worked very well, but it did
> > work.  You may look at using that as a starting point for the touch
> > panel part.
> >
>
> The touchscreen is the easiest part, since mousein can already take
> absolute coordinates.  I've already written that part and use the
> volume keys as button 2&3.  It works okay.
>
> I've been using bitsy/keyboard -n with the touch screen and it works
> fine for bootstrapping but not well by modern standards.  It's easy to
> fat-finger things because there's too many keys on screen and swipe
> input would be nice.  It also won't disable itself when the proximity
> sensor detects something close once that's exposed.
>
> >
> > For many of the sensors you may be in more or less uncharted
> > territory; the touch screen may look something like the Bitsy.  My
> > sense is that as long as you emit some reasonable data from those
> > devices you're ok, as presumably most of the interesting processing
> > would happen in userspace.  If it were me, I'd start prototyping with
> > what you have above, and then fine tune your data formats as you get a
> > sense for what you really need.
> >
> >         - Dan C.
>
> The "most of the interesting processing would happen in userspace" bit
> is why I'm considering returning the raw sensor values rather than
> doing the work of converting to metric/real world values from the
> driver but I could be convinced that's a bad idea.
>
> - Dave
>
> ------------------------------------------
> 9fans: 9fans
> Permalink:
> https://9fans.topicbox.com/groups/9fans/Tdba6baeaeca1f668-M4c6ed87258794c2eb6f7e993
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

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

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

[adventures in9]

I've done a fair amount of work on i2c sensors in 9front.

The simplest way to get data out of them is to make program that reads
/dev/i2c/[address] and parses the data.

I've often gone the route of doing it Plan 9 style and making a file
system out of it.  This is really simple for one off readings.  For
continuous readings, like an accelerometer, you have to write the file
system code to loop through till interrupted, and then handle the
interrupt.

https://github.com/adventuresin9/ShatFS
That's the file system I've done so far for the Raspberry Pi Sense
Hat.  It includes an accel, gyro, and mag sensor.

Since Plan9 and 9Front do blocking reads by default, setting another
program to just read the continuous output for an accelerometer file
and then act when a new value comes in would be one way to handle it.

It has been a while since I looked at the Pine Phone schematics, but
some of these i2c devices can have a separate interrupt pin, usually
connected to GPIO.

On Mon, Mar 24, 2025 at 9:20 AM ron minnich <rminnich@gmail.com> wrote:
>
> I like your raw data from kernel idea, putting interesting processing in user spaces makes bug fixes ever so much easier :-)
>
> On Mon, Mar 24, 2025 at 7:09 AM Dave MacFarlane via 9fans <9fans@9fans.net> wrote:
>>
>> Quoth Dan Cross <crossd@gmail.com>:
>> > The Bitsy kernel (for the Compaq iPaq) supported the touch screen on
>> > that device.  I don't recall that it worked very well, but it did
>> > work.  You may look at using that as a starting point for the touch
>> > panel part.
>> >
>>
>> The touchscreen is the easiest part, since mousein can already take
>> absolute coordinates.  I've already written that part and use the
>> volume keys as button 2&3.  It works okay.
>>
>> I've been using bitsy/keyboard -n with the touch screen and it works
>> fine for bootstrapping but not well by modern standards.  It's easy to
>> fat-finger things because there's too many keys on screen and swipe
>> input would be nice.  It also won't disable itself when the proximity
>> sensor detects something close once that's exposed.
>>
>> >
>> > For many of the sensors you may be in more or less uncharted
>> > territory; the touch screen may look something like the Bitsy.  My
>> > sense is that as long as you emit some reasonable data from those
>> > devices you're ok, as presumably most of the interesting processing
>> > would happen in userspace.  If it were me, I'd start prototyping with
>> > what you have above, and then fine tune your data formats as you get a
>> > sense for what you really need.
>> >
>> >         - Dan C.
>>
>> The "most of the interesting processing would happen in userspace" bit
>> is why I'm considering returning the raw sensor values rather than
>> doing the work of converting to metric/real world values from the
>> driver but I could be convinced that's a bad idea.
>>
>> - Dave
>>
>> ------------------------------------------
>> 9fans: 9fans
>> Permalink: https://9fans.topicbox.com/groups/9fans/Tdba6baeaeca1f668-M4c6ed87258794c2eb6f7e993
>> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Dave MacFarlane]

Quoth adventures in9 <adventuresin9@gmail.com>: 
> I've done a fair amount of work on i2c sensors in 9front. 
>  
> The simplest way to get data out of them is to make program that reads 
> /dev/i2c/[address] and parses the data. 
>  
 
Yes, that's what I've done. 
 
> I've often gone the route of doing it Plan 9 style and making a file 
> system out of it.  This is really simple for one off readings.  For 
> continuous readings, like an accelerometer, you have to write the file 
> system code to loop through till interrupted, and then handle the 
> interrupt. 
 
That's what I'm planning on doing before putting them online somewhere. 
 
I'm a little stuck on how to communicate that an interrupt happened 
to the userspace program that's reading /dev/i2c*/ and exposing the 
filesystem. 
 
I had considered making a /dev/archevents file from devarch that 
tells the reader when an event occured, but doing that in a way 
that allows multiple readers seems non-trivial and it wouldn't be 
useful if it was exclusive because only one fs would be able to 
access it and get all events. 
 
(My userspace touchscreen mouse emulator is polling the i2c address 
without interrupts right now, though I've gotten the IRQ to trigger in 
the kernel.) 
 
- Dave 

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

[adventures in9]

Looks like the Goodix GT917S touch sensor has its own interrupt pin.
The usual set up for these is to wire that to some gpio pin, and when
gpio senses a change in that pin, it can send an interrupt to the gic.

Looks like the expansion pogo pins also provide an interrupt line.

On Tue, Mar 25, 2025 at 10:07 PM Dave MacFarlane <driusan@driusan.net> wrote:
>
> Quoth adventures in9 <adventuresin9@gmail.com>:
> > I've done a fair amount of work on i2c sensors in 9front.
> >
> > The simplest way to get data out of them is to make program that reads
> > /dev/i2c/[address] and parses the data.
> >
>
> Yes, that's what I've done.
>
> > I've often gone the route of doing it Plan 9 style and making a file
> > system out of it.  This is really simple for one off readings.  For
> > continuous readings, like an accelerometer, you have to write the file
> > system code to loop through till interrupted, and then handle the
> > interrupt.
>
> That's what I'm planning on doing before putting them online somewhere.
>
> I'm a little stuck on how to communicate that an interrupt happened
> to the userspace program that's reading /dev/i2c*/ and exposing the
> filesystem.
>
> I had considered making a /dev/archevents file from devarch that
> tells the reader when an event occured, but doing that in a way
> that allows multiple readers seems non-trivial and it wouldn't be
> useful if it was exclusive because only one fs would be able to
> access it and get all events.
>
> (My userspace touchscreen mouse emulator is polling the i2c address
> without interrupts right now, though I've gotten the IRQ to trigger in
> the kernel.)
>
> - Dave