On 7/29/06, Vojtech Pavlik <vojtech@xxxxxxx> wrote:
I think we're hitting a fundamental problem with sysfs/hotplug/udev here. It was created to get fixed, non-changing names of devices in /dev, so that they'd be easy to enter into configuration files. Yet applications today want automatic discovery of devices and don't want to rely on udev getting the names right. We should make our minds up, and decide whether we want the 'devices are in /dev and applications just need to open the filename' or the 'an application will find the device itself' approach.
I think what people want from device choice is a reasonable default plus a convenient way to override things. The former is handled nicely by distributions' udev rules, while the latter is best done by providing fixed paths. As an end-user, if I know my favorite joystick is on a specific USB port (hence a specific syfs directory), then I want to tell neverball "use that one" without setting up nasty udev rules or playing major:minor matchup. Yes, that's bypassing the Proper Udevian Way of Doing Things, but it's so much easier and Unix-like that we really should make it possible (though not by default!). Security issues aside (for a moment): Is there any reason not to provide real device inodes on sysfs, instead of just a textual /sys/foo/dev? And then, maybe udev should symlink to those device files under /sys instead of creating its own? This would tie the two systems together rather elegantly.
This reminds me very much of the Joerg Schilling discussion (flamewar) of enumerating CD-burners. Most people on the kernel mailing list just wanted to enter the name of the device node on the cdrecord command line. Yet Joerg insisted that the application should do the discovery.
I think there's a lot more to *that* flamewar - such as unwavering belief in generic scsi...
> If you rattle your ThinkPad this badly, latency in Neverball is going > to be the least of your problems. :-) HDAPS, as explained above, doesn't have huge latency impact. The reason to have high update rates for input devices (mice nowadays run at 100 Hz refresh usually, gaming mice up to 1 kHz), is to not introduce additional delay to the user->computer->user closed control loop. The less delay, the better stability of the control loop and the better results in the game. The limiting factor is usually 3D rendering, but a 10 Hz joystick will still kill the experience by inducing a much larger delay.
Yes, I understand. I just pointed out that in the specific case of system accelerometer readouts, either the readouts change very slowly or your laptop is being rattled into an early death.
Sort of a 'reverse select'.
Exactly. Shem - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
