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?
> 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.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
