Re: hid-sensor-custom: async notification for input-report sysfs attributes? (human presence / attention sensors)

[srinivas pandruvada <srinivas.pandruvada@linux.intel.com>]

On Mon, 2026-07-27 at 11:38 +0530, Daniel Paul Perinchery wrote:
> Apologies — my last message went to Srinivas directly instead of the
> whole thread. Reposting here so it's visible to everyone and gets
> archived properly:
> 
Hi,

> Hi,
> 
> Thanks, this does help. I got it running and poll()/read() on
> /dev/HID-SENSOR-2000e1.3.auto does work. Two things I wasn't
> expecting, and wanted to check with you before going further:
> 
> 1. The reports arrive continuously, roughly every 100ms, whether or
> not anything actually changed (matches property-report-interval on
> this device, which reads 100). property-reporting-state reads 2
> ("Threshold Events" per the HID sensor usage table), which I'd
> assumed
> meant the async path would only push on a real threshold crossing --
> but empirically it's a steady ~10Hz stream throughout, including long
> stretches where the sensor value isn't changing. Is that expected for
> this reporting-state value on the async report path specifically, or
> is there a separate control I'm missing to actually get
> sparse/event-only pushes out of the misc device (vs. it just always
> streaming at the configured report interval regardless of
> reporting-state)?
> 

That is up to the hub. The reporting interval just tells that it should
not report less that that interval.
There is a sensitivity usage IDs 0x20030F , 0x200310 or  0x200310.
But they are optional, but if hub provides then, you can try that.


> 2. Every sample's usage_id field comes back as 0x002000e1, i.e. the
> collection's own usage (hsdev->usage), not the usage of whichever
> individual input field the report is carrying. This instance
> (2000e1.3.auto) has five input fields under it in sysfs
> (input-0-200201 through input-4-2004b1), so I think each 11-byte
> payload is a packed report containing some/all of those fields
> together, keyed by byte offset rather than by usage_id per sample. Is
> there a way to get the per-field usage or offset table from userspace
> (something under sysfs or a report-descriptor dump via hidraw) so I
> don't have to reverse-engineer the byte layout empirically by
> correlating against the -value sysfs files field by field?
> 

There is no individual field reporting by the hub.

Thanks,
Srinivas

> My use case is specifically the human-presence input (2004b1) for a
> walk-away lock/dim daemon, so what I actually want is: wake up only
> when *that* field changes, ideally without also waking up for the
> other four fields' updates every 100ms if they're unrelated to
> presence. Let me know if that's realistically achievable with this
> interface as-is, or if it'd need something added on the kernel side
> after all (which circles back to my original question -- happy to go
> either direction depending on what you'd recommend).
> 
> Thanks again for the pointer, this is a big step forward from polling
> sysfs.
> 
> Daniel Paul
> 
> On Fri, Jul 24, 2026 at 9:00 PM srinivas pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> > 
> > Hi,
> > 
> > On Fri, 2026-07-24 at 12:42 +0530, Daniel Paul Perinchery wrote:
> > > Hi,
> > > 
> > > I've been investigating why userspace can't efficiently watch a
> > > hid-sensor-custom input-report value (specifically a human-
> > > presence
> > > sensor, HID usage 2000e1, on an AMD Sensor Fusion Hub / amd_sfh
> > > platform) for changes without polling, and wanted to check
> > > whether
> > > there's interest in closing this gap before I try to write
> > > anything.
> > > 
> > > Setup: Lenovo IdeaPad Pro 5 14AKP10, AMD Ryzen AI 7 350, kernel
> > > 7.0.13
> > > (Debian/Parrot, but this is stock hid-sensor-custom.c). Presence
> > > and
> > > gaze/attention are exposed as separate logical sensors under the
> > > same
> > > physical hub (HID-SENSOR-2000e1.x.auto), each with the usual
> > > auto-generated input-N-<usage>-value sysfs attribute.
> > > 
> > > What I found tracing show_value() in hid-sensor-custom.c: for
> > > input
> > > reports, it calls sensor_hub_input_attr_get_raw_value(...,
> > > report_id,
> > > SENSOR_HUB_SYNC, false) -- i.e. every read of the -value file
> > > issues
> > > a
> > > synchronous GET_REPORT to the hub and returns the live answer.
> > > There's
> > > no cached field backing that attribute, so there's nothing for a
> > > notify-on-change mechanism to attach to on that path.
> > > 
> > > Separately, hid_sensor_capture_sample() *is* a genuine async
> > > callback
> > > fired on hub-pushed input reports, but as far as I can tell it
> > > only
> > > feeds the raw kfifo behind the driver's misc-device streaming
> > > interface (custom_dev), gated on test_bit(0,
> > > &sensor_inst->misc_opened). It doesn't appear to update any per-
> > > field
> > > cached value, so it isn't reachable from the sysfs show_value()
> > > path
> > > either.
> > > 
> > > Net effect: there's no way for a userspace consumer to poll()/
> > > select() on the -value file and be woken only on real hardware
> > > events.
> > 
> > 
> > I have a test program for poll(). Attached poll part.
> > 
> > #define DEVICE_PATH "/dev/HID-SENSOR-2000e1.2.auto"
> > #define BUFFER_SIZE 256
> > 
> > int main(int argc, char *argv[])
> > {
> >         int fd;
> >         struct pollfd pfd;
> >         char buffer[BUFFER_SIZE];
> >         int ret;
> >         struct sigaction sa;
> > 
> >         if (argc < 2) {
> >                 printf("syntax %s sample_interval\n", argv[0]);
> >                 exit(0);
> >         }
> > 
> > 
> >         // 1. Set up Ctrl+C signal handler
> >         sa.sa_handler = handle_sigint;
> >         sigemptyset(&sa.sa_mask);
> >         sa.sa_flags = 0; // Don't use SA_RESTART so poll() unblocks
> > on
> > signal
> >         if (sigaction(SIGINT, &sa, NULL) < 0) {
> >                 perror("Error setting up signal handler");
> >                 return -1;
> >         }
> > 
> >         enable_sensor(1);
> > 
> >         // 2. Open the misc device
> >         fd = open(DEVICE_PATH, O_RDONLY | O_NONBLOCK);
> >         if (fd < 0) {
> >                 perror("Failed to open device");
> >                 return -1;
> >         }
> > 
> >         // 3. Configure poll structure
> >         pfd.fd = fd;
> >         pfd.events = POLLIN;
> > 
> >         printf("Polling loop started. Press Ctrl+C to exit
> > safely.\n");
> > 
> >         // 4. Main event loop
> >         while (keep_running) {
> >                 printf("Waiting for data...\n");
> > 
> >                 ret = poll(&pfd, 1, -1);
> > 
> >                 if (ret < 0) {
> >                         // Signal interrupted poll, loop will exit
> > if
> > it was SIGINT
> >                         continue;
> >                 }
> > 
> >                 if (ret == 0) {
> >                         // Timeout reached with no data
> >                         continue;
> >                 }
> > 
> >                 // 5. Handle readable data event
> >                 if (pfd.revents & POLLIN) {
> >                         rx_tsc = read_rdtsc();
> >                         ssize_t bytes_read = read(fd, buffer,
> > sizeof(buffer) - 1);
> >                         if (bytes_read > 0) {
> >                                 time_t tm;
> > 
> >                                 buffer[bytes_read] = '\0'; // Null-
> > terminate string
> >                                 printf("tm:%ld Received %ld bytes:
> > %s\n", time(&tm), (long)bytes_read, buffer);
> >                                 read_time_stamp(buffer,
> > bytes_read);
> >                         } else if (bytes_read < 0) {
> >                                 perror("Read error");
> >                         }
> >                 }
> >         }
> > 
> >         // 6. Cleanup
> >         printf("\nExiting program cleanly...\n");
> >         close(fd);
> > 
> >         enable_sensor(0);
> > 
> >         return 0;
> > }
> > 
> > Does it help.
> > 
> > Thanks,
> > Srinivas
> > 
> > 
> > > The hub itself is already configured for threshold-based
> > > reporting
> > > (property-reporting-state = 2, i.e. "Threshold Events") in my
> > > case,
> > > so
> > > the inefficiency is entirely on the kernel/sysfs side --
> > > userspace
> > > has
> > > to fall back to timed re-reads of a synchronous, firmware-round-
> > > trip
> > > attribute, which is more expensive per-read than a typical cached
> > > sysfs value and awkward to size a safe polling interval for.
> > > 
> > > This seems like a real gap for the presence/proximity use case
> > > specifically (walk-away lock, auto-dim, etc.), which is
> > > inherently
> > > event-oriented and is exactly the kind of feature vendors
> > > implement
> > > natively on Windows via push notifications from the same class of
> > > sensor.
> > > 
> > > Before I put together a patch I wanted to ask: is there interest
> > > in
> > > adding async caching + sysfs_notify() (or sysfs_notify_dirent(),
> > > if
> > > attrs end up carrying a stored kernfs_node) for input-report
> > > values
> > > specifically, sourced from hid_sensor_capture_sample()'s existing
> > > async path? Rough shape as I see it:
> > > 
> > >   - add a cached "last input value" (+ a bool "valid") per
> > > relevant
> > > field in struct hid_sensor_custom_field
> > >   - in hid_sensor_capture_sample(), in addition to (or instead
> > > of,
> > > behind a config/attr) feeding the misc-device fifo, decode and
> > > store
> > > the value for the matching field, then sysfs_notify() its -value
> > > attribute
> > >   - leave show_value()'s SENSOR_HUB_SYNC path untouched for
> > > feature
> > > reports and for any input attrs that never get an async report,
> > > so
> > > nothing regresses for existing consumers
> > > 
> > > Happy to be told this already exists via a different interface
> > > I've
> > > missed (I did look at whether this should just go through the IIO
> > > buffered/trigger interface instead, given some other hid-sensor-*
> > > drivers are IIO-backed -- but hid-sensor-custom exposes
> > > vendor/custom
> > > usages directly via this sysfs shape rather than IIO channels, so
> > > I
> > > wasn't sure that's the right layer to add it at). Also open to
> > > being
> > > told the misc-device/fifo interface is meant to be the async
> > > consumption path already and userspace tools should be using that
> > > instead of polling -value -- if so, is there existing
> > > tooling/docs
> > > for
> > > that path I should be pointing presence-detection use cases at?
> > > 
> > > Not attaching a patch yet since I'd rather get a read on the
> > > right
> > > approach (and whether it's wanted at all) before writing one.
> > > 
> > > Thanks,
> > > Daniel Paul