From f6b8e0eae4374f339487a33e3e4fe5462d5816e1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Frings-F=C3=BCrst?= Date: Sat, 25 Nov 2017 10:16:00 +0100 Subject: New upstream version 2.0.0 --- doc/Installing_Linux.html | 839 +++++++++++++++++++++++----------------------- 1 file changed, 423 insertions(+), 416 deletions(-) mode change 100644 => 100755 doc/Installing_Linux.html (limited to 'doc/Installing_Linux.html') diff --git a/doc/Installing_Linux.html b/doc/Installing_Linux.html old mode 100644 new mode 100755 index dc9a044..8e4795c --- a/doc/Installing_Linux.html +++ b/doc/Installing_Linux.html @@ -1,49 +1,49 @@ - - - - - - - Argyll Installation on Linux - - -

Installing the software on Linux with X11
-

-
- You will need to unpack the downloaded file in the location you have - chosen to hold the executable files. Typically this might be in /usr/local/, or perhaps $HOME/bin/. You would then - unpack the files using tar -zxf - archivename.tgz, which will - create a directory Argyll_VX.X.X, - where X.X.X is the version number, and the executables will be in Argyll_VX.X.X/bin You will also - have to configure your $PATH environment variable to give access to - the executables from your command line environment. The .tgz file - also contains several useful reference files (such as scanner chart - recognition templates, sample illumination spectrum etc.) in the ref - sub-directory, as well as all the current HTML documentation in a - doc sub-directory. You may want to copy things to more standard - locations such as /usr/local/bin, /usr/local/argyll/bin etc., - depending on the conventions used on your system.
-
- Some systems (Fedora ?) seem to be missing normal X11 libraries like - libXss.so, so you may have to install libXScrnSaver, - i.e. "sudo dnf install libXScrnSaver".
-
- Note on the system bell:
-
- When reading strips using the Eye-One Pro or ColorMunki instrument, - the system bell is used to indicate when the instrument the ready to - be used, and to provide feedback on any problems. On some Linux - installations the system bell may be disabled. As well as checking - the terminal and GUI sound preferences, you may have to enable the - used of the PC speaker driver, which can be done by adding the + + + + + + + Argyll Installation on Linux + + +

Installing the software on Linux with X11
+

+
+ You will need to unpack the downloaded file in the location you have + chosen to hold the executable files. Typically this might be in /usr/local/, or perhaps $HOME/bin/. You would then + unpack the files using tar -zxf + archivename.tgz, which will + create a directory Argyll_VX.X.X, + where X.X.X is the version number, and the executables will be in Argyll_VX.X.X/bin You will also + have to configure your $PATH environment variable to give access to + the executables from your command line environment. The .tgz file + also contains several useful reference files (such as scanner chart + recognition templates, sample illumination spectrum etc.) in the ref + sub-directory, as well as all the current HTML documentation in a + doc sub-directory. You may want to copy things to more standard + locations such as /usr/local/bin, /usr/local/argyll/bin etc., + depending on the conventions used on your system.
+
+ Some systems (Fedora ?) seem to be missing normal X11 libraries like + libXss.so, so you may have to install libXScrnSaver, + i.e. "sudo dnf install libXScrnSaver".
+
+ Note on the system bell:
+
+ When reading strips using the Eye-One Pro or ColorMunki instrument, + the system bell is used to indicate when the instrument the ready to + be used, and to provide feedback on any problems. On some Linux + installations the system bell may be disabled. As well as checking + the terminal and GUI sound preferences, you may have to enable the + used of the PC speaker driver, which can be done by adding the command /sbin/modprobe pcspkr to @@ -57,8 +57,9 @@ - - the /etc/rc.local startup + + + the /etc/rc.local startup script. You may also have to run xset @@ -72,213 +73,215 @@ - - b 100 1000 100 in your local setup, if you are running in - an X11 environment. You can check that the system bell is operating - by doing an "echo ^G", where ^G is ctrl-G.
-
- Note on X11 multi-monitor - setups:
-
- When working with a multi-monitor X11 configuration, note that you - will only be able to individually calibrate monitors if the - multi-window extension you are using (if any), supports access to - the individual screen Video LUT tables that are used for - calibration. The native X11 multi-screen addressing supports this, - as does the Xinerama extension, and XRandR V1.2.
-
- The proprietary NVidia TwinView and ATI MergeFB extensions do not - currently support access to the individual screen Video LUTs, so - calibration of each screen independently is impossible if either of - these extensions are running. You can switch to using Xinerama to - solve this problem, or you can try doing a calibration for the - screens that do have accessible Video LUTs with these proprietary - extensions, or ignore calibration and rely purely on display - profiling. Use the dispwin tool to figure out what works on your - system. The NVidia ATI binary drivers do not seem to properly - support XRandR V1.2 either, even though they claim to do so. You may - have to set the ARGYLL_IGNORE_XRANDR1_2 - environment variable if the XRandR V1.2 extension is faulty.
-
- If these limitations trouble you, then as a valuable customer of - NVidia or AMD/ATI, perhaps you should contact them and urge them to - fix the problems with Video LUT access in their proprietary - multi-monitor extensions and XRandR implementation, bringing their - support for multi-monitors on X11 up to the same standards as other - operating systems. Ask them to add full and correct support for the - XRandR V1.2 extension.
-
- Fixing access to Video LUTs:
-
- Some users have noted that their default X11 installation doesn't - properly enable access to the video card Video Lookup Tables - (RAMDAC). The Video LUTs are used for display calibration purposes, - and a warning will be issues by the dispcal and dispread - tools if there is a problem with this. Without access to the - VideoLUTs, you won't be able to use display calibration.
-
- The problem may be because certain X11 extensions aren't being - loaded by default. You may want to check that you have
-
-   Load  "extmod"
-
- in the appropriate (or any) section of - your Xorg.conf file, to allow the XF86Video LUT - extensions to function correctly.
-
- Another source of problems is if the display isn't configured with a - suitable visual. Typically for high quality color you need to be - using at least 24 bits per - pixel (8 Bits for each of Red, Green and Blue channels), but more - importantly the number of entries in the the VideoLUTs needs to - match the depth of the screen. So if the VideoLUTs have 256 entries - per channel, then the screen must be using 8 bits per channel to - match. Or 64 entries and 6 bits. Or 4096 entries and 12 bits, etc. - Running "dispwin -D" may give some clues as to what the nature of - the problem is. You might have to look into your xorg.conf or XRANDR - setup, or on some distributions there will be some configuration - program that will let you choose the display configuration (ie. YaST - or SaX2 on openSUSE, etc.).
-
- Setting up instrument access:
-
- By default most Linux based systems make devices - inaccessible to user mode programs, so it is necessary to make some - modification to your permissions so that Argyll tools are able to - access the Color Measurement Instruments. In order from newest to - oldest, the following sub-systems may need to be configured to - permit this:
-
-   No device - configuration needed when running from the console:
-
-     Mandriva 2008.0 default - installation
-
-
  USB instruments - access using udev:
-     Ubuntu 10.04
-     Fedora - Core 8
-     Mandriva 2008.1
-     OpenSuSE 10.3
-     Ubuntu 7.1
-     Kubuntu 7.1
-     Debian 4.0
-
  USB instruments access using hotplug:
-    Red Hat 4.0
-    Fedora Core 4
-    Fedora Core 3
-    Fedora Core 2
-
-
  Serial instrument access:
-    All
-
- NOTE: That mtp-probe - /  libmtp been known - to interfere with device access, particularly the Spyder 3 and - DTP94. Recent versions of the libmtp should ignore any instrument - marked as COLOR_MEASUREMENT_DEVICE by the - /etc/udev/rules.d/55-Argyll.rules file, but for older systems you - probably need to disable libmtp (look in the udev configuration).
-
- The JETI specbos 1211, 1201, - 1511, 1501 and the Klien K10A makes use of the FTDI Virtual COM - Port Drivers (VCP), that should come with any recent version - of Linux. Older versions of Linux may not support the FTDI FT231XS - chip that the JETI specbos 1511, 1501 use. You may - have to add yourself to the - tty, uucp - or dialout group to have permission to open the - instrument.
-
- -
-
No - device configuration needed:
- A few systems have in place  a security configuration such that - anyone logging in at the console of a machine has access to all the - local devices.
- -
USB - instruments access using udev with existing /etc/udev/rules.d or - /usr/lib/udev/rules.d/69-cd-sensors.rules - file.
-
- Recent Fedora based - systems include Gnome Color Manager, which comes with a udev rule - for color instruments. You can check this by looking for the /etc/udev/rules.d or in /usr/lib/udev/rules.d/69-cd-sensors.rules - file. If this exists and is up to date enough to include the - instrument you want to use, then all you have to do is add yourself - to the colord group, ie:
-
-    sudo usermod -a -G colord $USER
-
- If the 69-cd-sensors.rules file is out of date and does not - include the latest instruments supported by Argyll, then the - simplest thing to do is to replace the 69-cd-sensors.rules - file with the usb/55-Argyll.rules. You will need - to do this as root, and set the owner as root, group root, - permissions 644. You may need to re-plug in your instrument to get - changes to the udev rules recognised.
-
USB - instruments access using udev, with no existing /etc/udev/rules.d or /usr/lib/udev/rules.d/69-cd-sensors.rules - file.
-
- Most recent systems use udev to manage device names and permissions, - but by default color instruments may not be accessible to normal - system users.
- To solve this a udev rule file needs to be added that modifies the - group and permission of any Color Measurement Instruments, and you - may then need to add yourself to that group.
-
- First check whether other rules are in /etc/udev/rules.d or in /usr/lib/udev/rules.d, - and use the appropriate directory.
- (You may also want to check in that directory whether - 55-Argyll.rules or some other .rules file that is setup to enable - color instruments already exists in that directory.)
-
- Copy the file usb/55-Argyll.rules from the binary or source - distribution into /etc/udev/rules.d/55-Argyll.rules + + + b 100 1000 100 in your local setup, if you are running in + an X11 environment. You can check that the system bell is operating + by doing an "echo ^G", where ^G is ctrl-G.
+
+ Note on X11 multi-monitor + setups:
+
+ When working with a multi-monitor X11 configuration, note that you + will only be able to individually calibrate monitors if the + multi-window extension you are using (if any), supports access to + the individual screen Video LUT tables that are used for + calibration. The native X11 multi-screen addressing supports this, + as does the Xinerama extension, and XRandR V1.2.
+
+ The proprietary NVidia TwinView and ATI MergeFB extensions do not + currently support access to the individual screen Video LUTs, so + calibration of each screen independently is impossible if either of + these extensions are running. You can switch to using Xinerama to + solve this problem, or you can try doing a calibration for the + screens that do have accessible Video LUTs with these proprietary + extensions, or ignore calibration and rely purely on display + profiling. Use the dispwin tool to figure out what works on your + system. The NVidia ATI binary drivers do not seem to properly + support XRandR V1.2 either, even though they claim to do so. You may + have to set the ARGYLL_IGNORE_XRANDR1_2 + environment variable if the XRandR V1.2 extension is faulty.
+
+ If these limitations trouble you, then as a valuable customer of + NVidia or AMD/ATI, perhaps you should contact them and urge them to + fix the problems with Video LUT access in their proprietary + multi-monitor extensions and XRandR implementation, bringing their + support for multi-monitors on X11 up to the same standards as other + operating systems. Ask them to add full and correct support for the + XRandR V1.2 extension.
+
+ Fixing access to Video LUTs:
+
+ Some users have noted that their default X11 installation doesn't + properly enable access to the video card Video Lookup Tables + (RAMDAC). The Video LUTs are used for display calibration purposes, + and a warning will be issues by the dispcal and dispread + tools if there is a problem with this. Without access to the + VideoLUTs, you won't be able to use display calibration.
+
+ The problem may be because certain X11 extensions aren't being + loaded by default. You may want to check that you have
+
+   Load  "extmod"
+
+ in the appropriate (or any) section of + your Xorg.conf file, to allow the XF86Video LUT + extensions to function correctly.
+
+ Another source of problems is if the display isn't configured with a + suitable visual. Typically for high quality color you need to be + using at least 24 bits per + pixel (8 Bits for each of Red, Green and Blue channels), but more + importantly the number of entries in the the VideoLUTs needs to + match the depth of the screen. So if the VideoLUTs have 256 entries + per channel, then the screen must be using 8 bits per channel to + match. Or 64 entries and 6 bits. Or 4096 entries and 12 bits, etc. + Running "dispwin -D" may give some clues as to what the nature of + the problem is. You might have to look into your xorg.conf or XRANDR + setup, or on some distributions there will be some configuration + program that will let you choose the display configuration (ie. YaST + or SaX2 on openSUSE, etc.).
+
+ Setting up instrument access:
+
+ By default most Linux based systems make devices + inaccessible to user mode programs, so it is necessary to make some + modification to your permissions so that Argyll tools are able to + access the Color Measurement Instruments. In order from newest to + oldest, the following sub-systems may need to be configured to + permit this:
+
+   No device + configuration needed when running from the console:
+
+     Mandriva 2008.0 default + installation
+
+
  USB instruments + access using udev:
+     Ubuntu 10.04
+     Fedora + Core 8
+     Mandriva 2008.1
+     OpenSuSE 10.3
+     Ubuntu 7.1
+     Kubuntu 7.1
+     Debian 4.0
+
  USB instruments access using hotplug:
+    Red Hat 4.0
+    Fedora Core 4
+    Fedora Core 3
+    Fedora Core 2
+
+
  Serial instrument access:
+    All
+
+ NOTE: That mtp-probe + /  libmtp been known + to interfere with device access, particularly the Spyder 3 and + DTP94. Recent versions of the libmtp should ignore any instrument + marked as COLOR_MEASUREMENT_DEVICE by the + /etc/udev/rules.d/55-Argyll.rules file, but for older systems you + probably need to disable libmtp (look in the udev configuration).
+
+ The JETI specbos 1211, 1201, + 1511, 1501 and the Klien K10A makes use of the FTDI Virtual COM + Port Drivers (VCP), that should come with any recent version + of Linux. Older versions of Linux may not support the FTDI FT231XS + chip that the JETI specbos 1511, 1501 use. You may + have to add yourself to the + tty, uucp + or dialout group to have permission to open the + instrument.
+
+ +
+
No + device configuration needed:
+ A few systems have in place  a security configuration such that + anyone logging in at the console of a machine has access to all the + local devices.
+ +
USB + instruments access using udev with existing /etc/udev/rules.d or + /usr/lib/udev/rules.d/69-cd-sensors.rules + file.
+
+ Recent Fedora based + systems include Gnome Color Manager, which comes with a udev rule + for color instruments. You can check this by looking for the /etc/udev/rules.d or in /usr/lib/udev/rules.d/69-cd-sensors.rules + file. If this exists and is up to date enough to include the + instrument you want to use, then all you have to do is add yourself + to the colord group, ie:
+
+    sudo usermod -a -G colord $USER
+
+ If the 69-cd-sensors.rules file is out of date and does not + include the latest instruments supported by Argyll, then the + simplest thing to do is to replace the 69-cd-sensors.rules + file with the usb/55-Argyll.rules. You will need + to do this as root, and set the owner as root, group root, + permissions 644. You may need to re-plug in your instrument to get + changes to the udev rules recognised.
+
USB + instruments access using udev, with no existing /etc/udev/rules.d or /usr/lib/udev/rules.d/69-cd-sensors.rules + file.
+
+ Most recent systems use udev to manage device names and permissions, + but by default color instruments may not be accessible to normal + system users.
+ To solve this a udev rule file needs to be added that modifies the + group and permission of any Color Measurement Instruments, and you + may then need to add yourself to that group.
+
+ First check whether other rules are in /etc/udev/rules.d or in /usr/lib/udev/rules.d, + and use the appropriate directory.
+ (You may also want to check in that directory whether + 55-Argyll.rules or some other .rules file that is setup to enable + color instruments already exists in that directory.)
+
+ Copy the file usb/55-Argyll.rules from the binary or source + distribution into /etc/udev/rules.d/55-Argyll.rules or /usr/lib/udev/rules.d/55-Argyll.rules - - (as appropriate) with owner root, group root, - permissions 644.
-
- If you are on an older system - that uses a udev that doesn't recognize the syntax used in - 55-Argyll.rules, or that doesn't have rules to create the libusb - /dev/bus/usb/00X/00Y device entries, you should install the usb/45-Argyll.rules file instead - - See below.
-
- On recent systems the new rules file will be notices as soon as you - plug the instrument in again.
+ + + (as appropriate) with owner root, group root, + permissions 644.
+
+ If you are on an older system + that uses a udev that doesn't recognize the syntax used in + 55-Argyll.rules, or that doesn't have rules to create the libusb + /dev/bus/usb/00X/00Y device entries, you should install the usb/45-Argyll.rules file instead + - See below.
+
+ On recent systems the new rules file will be notices as soon as you + plug the instrument in again.
On older systems you may need to run /sbin/udevtrigger,  @@ -293,62 +296,63 @@ - - /sbin/udevcontrol reload_rules or  /sbin/udevstart or reboot to get - the new file noticed.
-
- (You may want to refer to this - document for more guidance on modifying udev rules, as well as - this.)
-
- YOU THEN MAY NEED TO:
-
- If your system is not using - the ACL to manage device access for console users (the file /var/run/ConsoleKit/database - doesn't exist on your system), then you will need to add yourself to - the colord group, if you - are not already a member of it. You can do this either by using a - "Users and Groups" system administration tool, or on the command - line running as root:
-
-    sudo usermod -a -G colord $USER
-
- or
-     su root
-     usermod -a -G colord $USER
-
- (If the usermod program isn't found as root, it might be in - /usr/sbin, ie. use /usr/sbin/usermod .... etc.
-  If usermod doesn't recognize the -a flag try "usermod -A - colord $USER".
-  If this doesn't work you will have to run "id yourusername" to - list the current supplemental
-  groups, and add them plus colord using just "usermod -G - group1,group2,... yourusername")
-
- You may find that the colord group doesn't exist on - your system, and if so you will need to create it:
-
-   sudo groupadd -r colord
-
- and then add yourself to the colord group.
-
- You may have to log out and then in again for the groups to become - effective.
-
- You can check whether the instrument is being recognized and set to - the colord group by comparing the output of ls -l -R /dev/bus/usb without - and then with the instrument plugged in.
-
- You can test whether your instrument is accessible by plugging it in - and then running "spotread -?" and looking for it listed after the -c option.
+ + + /sbin/udevcontrol reload_rules or  /sbin/udevstart or reboot to get + the new file noticed.
+
+ (You may want to refer to this + document for more guidance on modifying udev rules, as well as + this.)
+
+ YOU THEN MAY NEED TO:
+
+ If your system is not using + the ACL to manage device access for console users (the file /var/run/ConsoleKit/database + doesn't exist on your system), then you will need to add yourself to + the colord group, if you + are not already a member of it. You can do this either by using a + "Users and Groups" system administration tool, or on the command + line running as root:
+
+    sudo usermod -a -G colord $USER
+
+ or
+     su root
+     usermod -a -G colord $USER
+
+ (If the usermod program isn't found as root, it might be in + /usr/sbin, ie. use /usr/sbin/usermod .... etc.
+  If usermod doesn't recognize the -a flag try "usermod -A + colord $USER".
+  If this doesn't work you will have to run "id yourusername" to + list the current supplemental
+  groups, and add them plus colord using just "usermod -G + group1,group2,... yourusername")
+
+ You may find that the colord group doesn't exist on + your system, and if so you will need to create it:
+
+   sudo groupadd -r colord
+
+ and then add yourself to the colord group.
+
+ You may have to log out and then in again for the groups to become + effective.
+
+ You can check whether the instrument is being recognized and set to + the colord group by comparing the output of ls -l -R /dev/bus/usb without + and then with the instrument plugged in.
+
+ You can test whether your instrument is accessible by plugging it in + and then running "spotread -?" and looking for it listed after the -c option.
USB instruments @@ -364,73 +368,74 @@ instruments - - access using hotplug:
-
- Under much older versions of Linux, - you should look into the hotplug system configuration for USB - devices. You know you are running this because the /etc/hotplug directory exists on - your system.
-
- Assuming we want to configure for all Argyll supported USB - instruments, copy the file usb/Argyll.usermap from the binary - or source distribution into  /etc/hotplug/usb/Argyll.usermap - with owner root, group root, permissions 644.
-
-
-  (For even older versions, append the lines above to /etc/hotplug/usb.usermap, and - you may have to run update-usb.usermap)
-
- Then copy the file usb/Argyll from the binary or source - distribution into /etc/hotplug/usb/Argyll - with owner root, group root, permissions 744.
-
- YOU THEN NEED TO:
-
- You will then need to add - yourself to the colord - group, if you are not already a member of it. You can do this either - by using a "Users and Groups" system administration tool, or on the - command line running as root:
-
-    sudo usermod -a -G colord $USER
-
- or
-     su root
-     usermod -a -G colord $USER
-
-
- (If the usermod program isn't found as root, it might be in - /usr/sbin, ie. use /usr/sbin/usermod .... etc.
-  If usermod doesn't recognize the -a flag try "usermod -A - colord $USER".
-  If this doesn't work you will have to run "id yourusername" to - list the current suplemental
-  groups, and add colord using just "usermod -G - group1,group2,... yourusername"
-  Another option may be to use gpasswd -a $USER colord))
-
- You may find that the colord - group doesn't exist on your system, and if so you will need to - create it:
-
-   sudo groupadd -r colord
-
- and then add yourself to the colord group.
-
- You may have to log out and then in again for the groups to become - effective.
-
- You can test whether your instrument is accessible by plugging it in - and then running "spotread -?" and looking for it listed after the -c option.
-  
+ + + access using hotplug:
+ + Under much older versions of Linux, + you should look into the hotplug system configuration for USB + devices. You know you are running this because the /etc/hotplug directory exists on + your system.
+
+ Assuming we want to configure for all Argyll supported USB + instruments, copy the file usb/Argyll.usermap from the binary + or source distribution into  /etc/hotplug/usb/Argyll.usermap + with owner root, group root, permissions 644.
+
+
+  (For even older versions, append the lines above to /etc/hotplug/usb.usermap, and + you may have to run update-usb.usermap)
+
+ Then copy the file usb/Argyll from the binary or source + distribution into /etc/hotplug/usb/Argyll + with owner root, group root, permissions 744.
+
+ YOU THEN NEED TO:
+
+ You will then need to add + yourself to the colord + group, if you are not already a member of it. You can do this either + by using a "Users and Groups" system administration tool, or on the + command line running as root:
+
+    sudo usermod -a -G colord $USER
+
+ or
+     su root
+     usermod -a -G colord $USER
+
+
+ (If the usermod program isn't found as root, it might be in + /usr/sbin, ie. use /usr/sbin/usermod .... etc.
+  If usermod doesn't recognize the -a flag try "usermod -A + colord $USER".
+  If this doesn't work you will have to run "id yourusername" to + list the current suplemental
+  groups, and add colord using just "usermod -G + group1,group2,... yourusername"
+  Another option may be to use gpasswd -a $USER colord))
+
+ You may find that the colord + group doesn't exist on your system, and if so you will need to + create it:
+
+   sudo groupadd -r colord
+
+ and then add yourself to the colord group.
+
+ You may have to log out and then in again for the groups to become + effective.
+
+ You can test whether your instrument is accessible by plugging it in + and then running "spotread -?" and looking for it listed after the -c option.
+  
Serial instruments @@ -446,47 +451,49 @@ instruments - - access:
-
- If you have a serial instrument then you may find that by default - you don't have permission to access the serial ports or a Serial to - USB adapter. Most systems make the serial ports available to any - user in the tty, uucp or dialout group, - so the best way of getting access to the serial ports is to add - yourself to the correct group. (You can identify the correct group - by looking at the group name shown by ls -l /dev/ttyS* )
-
-  You can add yourself to a group either by using a "Users - and Groups" system administration tool, or on the command line using - "usermod":
-
-     su root
-     usermod -a -G dialout $USER
-
- or
-
-    sudo usermod -a -G dialout $USER
-
- (If the usermod program isn't found as root, it might be in - /usr/sbin, ie. use /usr/sbin/usermod .... etc.
-  If usermod doesn't recognize the -a flag try "usermod -A - dialout $USER".
-  If this doesn't work you will have to run "id yourusername" to - list the current suplemental
-  groups, and add a tty, uucp or dialout group using just - "usermod -G group1,group2,... yourusername"
-  Another option may be to use gpasswd -a $USER dialout)
-
- You may have to log out and then in again for the group to become - effective.
- -

 
-  
-  
-  
-  
-  

- - + + + access:
+ + If you have a serial instrument then you may find that by default + you don't have permission to access the serial ports or a Serial to + USB adapter. Most systems make the serial ports available to any + user in the tty, uucp or dialout group, + so the best way of getting access to the serial ports is to add + yourself to the correct group. (You can identify the correct group + by looking at the group name shown by ls -l /dev/ttyS* )
+
+  You can add yourself to a group either by using a "Users + and Groups" system administration tool, or on the command line using + "usermod":
+
+     su root
+     usermod -a -G dialout $USER
+
+ or
+
+    sudo usermod -a -G dialout $USER
+
+ (If the usermod program isn't found as root, it might be in + /usr/sbin, ie. use /usr/sbin/usermod .... etc.
+  If usermod doesn't recognize the -a flag try "usermod -A + dialout $USER".
+  If this doesn't work you will have to run "id yourusername" to + list the current suplemental
+  groups, and add a tty, uucp or dialout group using just + "usermod -G group1,group2,... yourusername"
+  Another option may be to use gpasswd -a $USER dialout)
+
+ You may have to log out and then in again, or even re-boot your + system for the group to become effective.
+ +

 
+  
+  
+  
+  
+  

+ + -- cgit v1.2.3