010/10/19 Samu Onkalo <samu.p.onkalo@xxxxxxxxx>: > This is a driver for ROHM BH1770GLC and OSRAM SFH7770 combined > ALS and proximity sensor. > > Interface is sysfs based. The driver uses interrupts to provide new data. > The driver supports pm_runtime and regulator frameworks. > (...) > +static DEVICE_ATTR(prox0_raw_en, S_IRUGO | S_IWUSR, bh1770_prox_enable_show, > + bh1770_prox_enable_store); > +static DEVICE_ATTR(prox0_thresh_above1_value, S_IRUGO | S_IWUSR, > + bh1770_prox_abs_thres_show, > + bh1770_prox_abs_thres_store); > +static DEVICE_ATTR(prox0_thresh_above0_value, S_IRUGO | S_IWUSR, > + bh1770_get_prox_thres, > + bh1770_set_prox_thres); > +static DEVICE_ATTR(prox0_raw, S_IRUGO, bh1770_prox_result_show, NULL); So you have sysfs entries for enabling, calibrating hysteris (above/below) and the reading the raw value which I assume will be 0 (if nothing is in proximity) or 1 (if it is in proximity). These entries are pretty OK I think, but the transition from 0 to 1 which I assume will generate an interrupt and generate a new value in this attribute. But should it not hook into the input framework and generate a SW_FRONT_PROXIMITY event as well? I think this could be pretty helpful for generic userspace applications like X that want to use this event. Of course I can send a patch for this later, but I'd like to hear whether you agree on this or not. Yours, Linus Walleij -- To unsubscribe from this list: send the line "unsubscribe linux-input" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
