Re: [9fans] Re: 9phone

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

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=E2=80=AFAM Dave MacFarlane via 9fans <9fans@9f=
ans.net>
wrote:

> Quoth Dan Cross <[email protected]>:
> > 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-M4c6ed87258794c=
2eb6f7e993
> Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
>

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

<div dir=3D"ltr">I like your raw data from kernel idea, putting interesting=
 processing in user spaces makes bug fixes ever so much easier :-)</div><br=
><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D=
"gmail_attr">On Mon, Mar 24, 2025 at 7:09=E2=80=AFAM Dave MacFarlane via 9f=
ans &lt;<a href=3D"mailto:[email protected]">[email protected]</a>&gt; wrote:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,20=
4,204);padding-left:1ex">Quoth Dan Cross &lt;<a href=3D"mailto:crossd@gmail=
.com" target=3D"_blank">[email protected]</a>&gt;:<br>
&gt; The Bitsy kernel (for the Compaq iPaq) supported the touch screen on<b=
r>
&gt; that device.=C2=A0 I don&#39;t recall that it worked very well, but it=
 did<br>
&gt; work.=C2=A0 You may look at using that as a starting point for the tou=
ch<br>
&gt; panel part.<br>
&gt;<br>
<br>
The touchscreen is the easiest part, since mousein can already take<br>
absolute coordinates.=C2=A0 I&#39;ve already written that part and use the<=
br>
volume keys as button 2&amp;3.=C2=A0 It works okay.<br>
<br>
I&#39;ve been using bitsy/keyboard -n with the touch screen and it works<br=
>
fine for bootstrapping but not well by modern standards.=C2=A0 It&#39;s eas=
y to<br>
fat-finger things because there&#39;s too many keys on screen and swipe<br>
input would be nice.=C2=A0 It also won&#39;t disable itself when the proxim=
ity<br>
sensor detects something close once that&#39;s exposed.<br>
<br>
&gt; <br>
&gt; For many of the sensors you may be in more or less uncharted<br>
&gt; territory; the touch screen may look something like the Bitsy.=C2=A0 M=
y<br>
&gt; sense is that as long as you emit some reasonable data from those<br>
&gt; devices you&#39;re ok, as presumably most of the interesting processin=
g<br>
&gt; would happen in userspace.=C2=A0 If it were me, I&#39;d start prototyp=
ing with<br>
&gt; what you have above, and then fine tune your data formats as you get a=
<br>
&gt; sense for what you really need.<br>
&gt; <br>
&gt;=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0- Dan C.<br>
<br>
The &quot;most of the interesting processing would happen in userspace&quot=
; bit<br>
is why I&#39;m considering returning the raw sensor values rather than<br>
doing the work of converting to metric/real world values from the<br>
driver but I could be convinced that&#39;s a bad idea.<br>
<br>
- Dave<br>
<br>
------------------------------------------<br>
9fans: 9fans<br>
Permalink: <a href=3D"https://9fans.topicbox.com/groups/9fans/Tdba6baeaeca1=
f668-M4c6ed87258794c2eb6f7e993" rel=3D"noreferrer" target=3D"_blank">https:=
//9fans.topicbox.com/groups/9fans/Tdba6baeaeca1f668-M4c6ed87258794c2eb6f7e9=
93</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>

--0000000000007a8c0d063118e3b2--