Mikkel L. Ellertson wrote:
Karl F. Larsen wrote:
Mikkel L. Ellertson wrote:
Wolfgang S. Rupprecht wrote:
Is there any documentation for FC5's hotplug? I need to know the
format/location of the action scripts that get run when a new device
gets plugged in.
I have a usb GPS device (it looks like a serial port) that I'd like to
have recognized and have the device permissions automatically set to
allow the user access. Doing an su to root and "chmod 666
/dev/ttyXXX" every time I plug it in is getting old.
You should look at the udev and HAL documentation. Hotplug is not
really used any more. Chances are, you can do this with a udev rule,
and have it create a /dev/gps symlink at the same time.
Mikkel
Hello Mikkel, I was trying to get a ham radio appliance to work in
FC5 and my playing around got me to UDEV and I read all the man and info
pages on udev and decided if it takes an understanding of this to use
FC5 I will go back to FC2. And that is exactly what I did.
By the way, you say hotplug is no longer used and it is a part of
EVERY thought given to UDEV and all that mysterious stuff at
/etc/security/*. This stuff really made me wonder what Linux is coming
to. I was fat dumb and happy with Red Hat 9. I should have stayed there
:-)
Karl
I know what you mean. HAL and udev are a big change. But I think it
is worth it in the long run. For what you want, it should be a
simple udev rule. Basicly, you would put a rule in
/etc/udev/rules.d/10-local.rules (You may have to create it.) with
something like:
BUS="usb", SYSFS{serial}="<serial number of GPS device>",
NAME="gps", MODE="0666"
or
BUS="usb", SYSFS{vendor}="<GPM vender>", SYSFS{model}="<GPS model>",
NAME="GPS", MODE="0666"
Note that each rule in one line - they may be wrapped by the mail
client. You can also do things like specify the owner/group of the
device, add things like a symlink, etc. The thing is, this rule will
only be used if the serial number (rule 1) or vender and device
(rule 2) match the device you are plugging in. Because of the way
udev processes rules, the 10-local.rules is processed before the
default rules, and the first match is used. So other USB serial
devices are processed normally. But udev does not allow the fine
control that HAL does. With HAL, you can do things like assign the
ownership of the device to the owner of the console, run an
application, etc.
Think of HAL as a programming language for handling devices. The
thing that I think holds the most promise of HAL is that you can add
specific files for devices that will be used instead of the default
rules. So you could see devices come with a HAL rule set, just like
they come with device drivers for Windows. This could specify the
device name, a program to be run, or a desktop icon to use when the
device is attached. That way, when you bring home the GPS device,
you would install the HAL rule, and any specific software that comes
with it, and it would work anytime you plugged it in without you
having to do anything. (It could all be in an RPM...)
Mikkel
Hi Mikkel I am saving this message since you have explained a lot of
new features I am not aware of. But if you can send the HAL data in an
RPM that sounds very powerful.
My current problem is I think part of the application. I will write
the author with I hope enough meat that he can understand what is happening.
Karl
