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

[9fans] 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.

------------------------------------------
9fans: 9fans
Permalink: https://9fans.topicbox.com/groups/9fans/Tdba6baeaeca1f668-M4a55630be7c8fd7a6822472e
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription

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

[Dave MacFarlane via 9fans]

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

[ron minnich]

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

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