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