[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gphoto-devel
Subject:    [gphoto-devel] Minor Suggestion for UI in gphoto
From:       "Lawrence E. Widman" <widman () cardiothink ! com>
Date:       2000-11-17 15:36:54
[Download RAW message or body]

This is my first posting to this group.

Please accept my thanks for developing gphoto, which is
wonderful.

1.  I have a shiny new Olympus D-490 Zoom.  It works fine with
    gphoto under the D-200L and D-450Z configurations.

2.  While I was trying the camera out, I ran into an
    "unexplained failure" twice, in which the Summary was all
    zeros for no "good" reason.  After much head scratching, I
    realized that I had two processes competing for the serial
    port.  The first time it was the APC UPS detection daemon.
    The second time it was VMware.  VMware can be configured to
    use the serial port(s), and when it is it locks up the serial
    port when it's booted.  When neither process is running,
    gphoto works flawlessly (as long as the camera is powered
    up).

    Maybe other people have the same problem, and they would
    appreciate a tip that a port conflict may exist.

 I see in src/callbacks.c, in port_dialog(), near the bottom:
      if (( sd = open (serial_port, O_RDWR, 0) ) < 0) {
 
             sprintf(status, "Error: failed to open
             %s",serial_port);
             update_status(status);
             message_window ("Missing Serial Device Permissions",
                             "Please check the permissions "
                             "(see the manual).",
                 GTK_JUSTIFY_FILL);
         }
         else {
         ...   (all OK)
         } 
 
 The problem is that this doesn't detect whether a port is in
 use, it just detects whether the user can read and write to
 the port.  According to http://www.linuxdoc.org/HOWTO/-
 Serial-HOWTO-10.html it's actually impossible under linux to
 tell whether a port is available because the competing process
 may not have generated a lock file, changed permissions will
 have been detected by the above code, and the kernel doesn't
 support locking of serial ports.  It turns out VMware does
 create a LCK..ttyS<n> file in /var/lock, but the APC UPS
 daemon does not.
 
 So, I suggest the following 2 changes to gphoto:
 
 1.  In port_dialog(), Check for a lockfile (under linux, in
     /var/lock) for a file LCK..ttySn, where n is the port
     number.  If it's there, call error_dialog with a warning
     (and maybe let the user proceed if he/she wants).
 
 2.  In the libraries for the individual cameras, if the
     <camera>_get_camera_status(struct <camera>_status *status)
     call returns a structure that has only whatever it was
     initialized with (zeroes, currently), then warn the user
     that the camera wouldn't talk and maybe there is
     competition for the serial port, the camera power isn't
     on, etc.
 
 If these suggestions sound reasonable, I'll be happy to
 implement them.  I request three things:

 1.  An opinion from the list as to whether these changes would
     be acceptable,

 2.  Help with specifying the lock directory under OSs other
     than Linux, and

 3.  Regarding checking the camera status, a tip on whether
     it's possible to do it in one place higher than the
     libraries for individual cameras, so one piece of code
     would check the status of all cameras.  It looks like the
     status structure is tailored to each camera type, which
     means changing every instance of
     <camera>_get_camera_status().  That's OK unless there is a
     more elegant way to accomplish the task.
 
 Thanks - Larry Widman (widman@cardiothink.com)

[prev in list] [next in list] [prev in thread] [next in thread]