Messages in this thread | | | Date | Mon, 10 Sep 2007 22:18:08 +0200 | From | Yan Burman <> | Subject | Re: [Hdaps-devel] [PATCH 2.6.23-rc2] hwmon: HP Mobile Data Protection System 3D ACPI driver (resend) |
| |
Henrique de Moraes Holschuh wrote: > On Thu, 30 Aug 2007, Yan Burman wrote: > >>>> You can generate events on input devices, but I am not sure that's the >>>> best way to go about it for this. Things that block on read until an >>>> interrupt happens might work better. >>>> >>> You can do the latter via another (4th) input device. >>> >>> >> What's wrong with the stuff I did in mdps? a misc character device that >> acts like /dev/rtc. Why does it have to be input device oriented? >> > > I am fine with a char device that acts like /dev/rtc, but if we are doing > something as heavyweight as a char device, I'd rather we go full generic > netlink and send the various events over it. We'd have a netlink device > that sends everything over various "channels" and just one input device that > does joystick emulation, then. > > Can we use a simple sysfs attribute that blocks the caller on write and > returns immediately on read? If it has to be more complicated than that, I'd > rather we go the netlink path. Any other ideas that are not a char device, > not a netlink socket, not an input device node, and not a sysfs attribute? > > But, how are you going to make the sysfs attribute look generic so that application will not have to know whether to go to /sys/.../mdps /sys/.../hdaps/ or /sys/.../whatever?
I'd probably prefer netlink, since this way it's something more generic and if some more functionality is added, you don't need to start adding more sysfs attributes.
Sorry it took me a while to respond - I was too busy lately.
>> I also looked at what you did in the patches as well as the modified >> hdapsd. I'm doing the raw input device right now in the mdps, but I have a >> suggestion. >> >> It seems to me that right now there are at least 3 drivers that provide the >> same functionality - hdaps, ams and mdps. Why not create the input device >> that exports raw accelerometer data with a name that is generic - something >> like accel/input or something along those lines. This way hdapsd could work >> with any driver that provides the functionality without being hdaps >> specific. >> > > THAT is the idea, IMO. But the naming is userspace's problem (thorugh > udev), not ours :-) > > Or do you mean the "hardware port" part of the input device? If so, yes, we > should try to make standard names for those as that makes it easier for > userspace. > >
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |