Re: [RFC] Touchscreen driver API


Jon Medhurst (Tixy) <tixy@...>
 

On Tue, 2017-05-09 at 13:54 +0200, Tomasz Bursztyka wrote:
I don't know much about touchscreens myself but as a sensor, because it
basically is one,
is there any reason why you specifically did not make this with sensor API?

Some of the existing attributes and functions there seem really meant
for such usage.

If things are missing in sensor API, wouldn't it be worth improving that
API then?
So the sensor API (like most things in Zephyr) doesn't specify much in
the way dynamic behaviour, or implementation or usage constraints.
Specifically in this case, how often trigger handlers get called and
there interaction with calls to channel_get and sample_fetch.

So, for my driver, I've implementation so that the first call to
channel_get after a sample_fetch triggers a work item to enabled the
trigger callback for the next sample. Which means for suitably written
client code, we can guarantee to a) see all sample events and b) not
hang waiting for a callback.

This doesn't really help other people writing touchscreen drivers or
other users of my driver, as they won't know the usage semantics. But at
least my driver now uses an official Zephyr API, with the following
modification...

--- a/include/sensor.h
+++ b/include/sensor.h
@@ -110,6 +110,12 @@ enum sensor_channel {
        SENSOR_CHAN_GREEN,
        /** Altitude, in meters */
        SENSOR_CHAN_ALTITUDE,
+       /**
+        * Touchscreen X,Y and Z (pressure) samples, in device specific units.
+        * Higher pressure is lower Z values and the maximum Z integer value
+        * (0x7fffffff) indicates that the screen isn't being touched.
+        */
+       SENSOR_CHAN_TOUCHSCREEN_XYZ,
        /** All channels. */
        SENSOR_CHAN_ALL,
 };

--
Tixy

Join devel@lists.zephyrproject.org to automatically receive all group messages.