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 [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]
